En ce mardi 28 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 44.

Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• La communauté francophone
  • L'association
  • La documentation
• Comment se procurer Fedora Linux 44 ?

Expérience utilisateur

L'environnement de bureau GNOME est proposé dans sa version 50.

Après avoir introduit lors de la version précédente un moniteur du temps d'écran dans le panneau de configuration, ce menu s'étoffe avec la possibilité de configurer un réel contrôle parental. Ainsi il est possible de verrouiller l'écran automatiquement après un temps passé dans la journée sur l'ordinateur ou après une certaine heure. Il reste possible d'étendre l'usage de l'ordinateur manuellement en cas de besoin après validation par l'administrateur.

Côté accessibilité, le lecteur d'écran Orca se dote d'un rafraîchissement de son outil de configuration pour être aligné avec l'apparence des autres applications GNOME. Par défaut ses paramètres sont également globaux, évitant de devoir reconfigurer le lecteur d'écran pour chaque application bien que des personnalisations précises restent possibles application par application si nécessaire. Il est aussi possible de réduire les animations dans l'interface de GNOME pour éviter les distractions pour ceux qui en souffriraient.

Le lecteur de documents se dote, enfin, d'une possibilité d'annoter les documents autrement qu'en ajoutant un champ de texte dans une zone précise. Il est possible de surligner ou de tracer des lignes au sein du document et de varier le style de l'ensemble au gré des besoins.

Le navigateur de fichiers quant à lui continue dans l'amélioration des performances et de la stabilité, que ce soit un chargement des miniatures et icônes de documents plus rapide, ou une consommation moindre de mémoire pour l'application en général. Côté fonctionnel, le renommage de fichiers en masse a une interface plus claire et il est possible lors de la recherche de fichiers de sélectionner simultanément plusieurs filtres.

En terme de performances, pour ceux qui utilisent une session distante de GNOME la carte graphique de la machine qui reçoit le flux vidéo est sollicitée pour le décodage ce qui rend l'expérience bien plus fluide tout en consommant moins d'énergie. Pour ceux utilisant une carte graphique Nvidia l'expérience devrait être également plus stable par rapport aux versions précédentes. Il est possible de coupler l'accès distant avec une authentification Kerberos, de même il peut être exploité même si la session a été démarrée depuis un ordinateur sans écran tel un serveur.

Il y a eu de nombreuses améliorations pour l'affichage à fréquence variable et l'affichage avec mise à l'échelle fractionnée. Si ces fonctions étaient déjà activées dans Fedora, pour ceux bénéficiant d'un matériel compatible, elles bénéficient d'une plus grande stabilité. Les possesseurs d'une carte graphique Nvidia devraient également noter une plus grande fluidité dans l'interface. Le partage et la capture d'écran peuvent prendre en compte l'affichage HDR pour avoir le même rendu que sur l'écran physique. Enfin GNOME prend en charge le protocole des couleurs v2 de Wayland afin d'être compatible avec les évolutions futures des applications graphiques qui peuvent en faire un usage fin comme un éditeur d'images.

Le calendrier continue sa mutation. Dans un contexte professionnel, il permet maintenant de voir, pour un événement donné, qui a reçu l'invitation et parmi ces invités, lesquels doivent obligatoirement être présents. L'interface pour ajouter rapidement un nouvel événement a été revue pour être plus intuitive. Il est dorénavant possible d'exporter un calendrier complet avec le format ICS au lieu d'un événement seulement. L'interface prend en compte maintenant les paramètres régionaux concernant le premier jour de la semaine.

D'ailleurs il est possible au niveau de GNOME de changer ce paramètre du premier jour de la semaine. Pour les paramètres, les entrées et sorties sonores sont dissociées pour identifier clairement si on contrôle le volume d'une entrée ou d'une sortie audio.

Les variantes de Fedora reposant sur l'environnement KDE Plasma utiliseront le configurateur Plasma Setup pour la post installation de manière analogue à GNOME avec GNOME init setup. Cet utilitaire a été récemment introduit avec KDE Plasma 6.6. Les étapes redondantes au niveau d'Anaconda sont supprimées pour une plus grande cohérence. Ainsi les images Live comme non Live fourniront la même expérience ce qui sera particulièrement visible pour ceux utilisant la variante KDE Plasma Mobile. Et comme pour GNOME, il devient possible d'installer Fedora en mode OEM, où le système peut être installé et le premier utilisateur peut créer son compte et le configurer à sa guise sans nécessiter un compte factice à l'installation.

De même ces variantes utiliseront Plasma Login Manager (PLM) comme gestionnaire de connexions au lieu de SDDM. Ce changement a également été introduit dans KDE Plasma 6.6 pour avoir un contrôle total du projet KDE dans l'expérience utilisateur. L'objectif de Fedora est de suivre la décision du projet pour améliorer la maintenance et l'expérience utilisateur en ayant un tout intégré. Cependant — même si PLM dérive de SDDM — il reste légèrement moins personnalisable à ce stade. Ce changement n'affecte par défaut que les nouvelles installations. Pour ceux qui veulent en bénéficier après une mise à niveau, voici les commandes à exécuter :

$ sudo dnf install plasma-login-manager kcm-plasmalogin

$ sudo systemctl enable --force plasmalogin.service

L'environnement de bureau Budgie passe à la version 10.10 et tourne avec Wayland au lieu de X11. Il utilise labwc comme compositeur qui permet de définir des raccourcis claviers globaux, l'accélération du curseur de la souris, d'adapter le thème des applications en fonction de la configuration de l'environnement. La variante spin utilisera SDDM comme gestionnaire de connexions pour avoir une expérience native Wayland de bout en bout. Outre cela, l'environnement fournit un nouvel utilitaire pour configurer les écrans.

La variante Games Lab est remaniée pour passer de Xfce à KDE Plasma et ainsi utiliser Wayland pour avoir une couche graphique plus moderne. En effet Wayland permet de plus en plus d'exploiter le matériel moderne ce qui est particulièrement utile dans ce contexte. La liste des jeux fournis par défaut a été revue, la documentation autour rafraîchie pour rendre compte des progrès dans le domaine et une tentative de fournir certains correctifs pour gérer le matériel des jeux aux projets d'origine plutôt que de les garder dans Fedora ou d'autres distributions dérivées comme Bazzite.

Le module noyau NTSYNC est activé quand les paquets Steam ou WINE sont installés pour améliorer les performances et la compatibilité des applications Windows et en particulier les jeux. Cela passe par l'ajout du paquet ntsync-autoload qui une fois installé remplit ce rôle en écrivant ntsync dans le fichier /usr/lib/modules-load.d/ntsync.conf afin de charger ce module automatiquement.

Ce module noyau améliore les performances car globalement les applications Windows, mais en particulier les jeux, pouvaient synchroniser leurs fils d'exécution avec des sémaphores, mutex et événements via des primitives noyau Windows. Mais comme ces mécanismes ne sont pas disponibles dans le noyau Linux, WINE les émulait dans l'espace utilisateur ce qui a des performances moindre. Le module noyau fournit cette abstraction au sein du noyau Linux lui-même ce qui reproduit la conception originale de Windows à ce niveau.

Le spin MiracleWM remplace l'environnement nwg-shell avec Dank Material Shell (qui est basé sur QuickShell). En effet le premier était difficile à maintenir et à stabiliser avec des mises à jour qui cassaient fréquemment la compatibilité. L'expérience devrait donc être plus stable pour les utilisateurs et ils devraient disposer de plus de fonctionnalités également.

Le gestionnaire de paquets universel PackageKit, utilisé par GNOME Logiciels entre autre, exploite dorénavant dnf5 au lieu de la version précédente. Cela permet d'avoir une expérience unifiée quel que soit l'outil employé pour utiliser DNF dans l'arrière coulisse. En particulier, les bases de données internes ne seront plus dupliquées et l'historique des actions est ainsi unique. Les notifications de mise à jour et la réalisation des mises à niveau devrait être également plus fiables et efficaces.

L'installateur Anaconda ne fournira plus de configuration réseau par défaut pour les interfaces filaires mais uniquement pour les installations n'utilisant pas une image Live. Jusqu'ici, à l'installation il y a la possibilité de configurer les interfaces réseaux mais pour les interfaces filaires non configurées (pour l'être avec des outils dédiés plus tard, par exemple) une configuration par défaut basique et potentiellement inadaptée était installée. Cela pouvait poser des problèmes à certains utilisateurs, mais c'était aussi un effort de maintenance pour que les valeurs par défaut correspondent à celles de NetworkManager par exemple. Ce changement permet également d'ouvrir la voie à la réutilisation du module de configuration réseau de Cockpit dans le futur.

La suite TeXLive nouveau millésime 2025 est proposée. Fedora en profite pour revoir l'empaquetage passant d'un SRPM unique pour le millier de modules à une cinquantaine. Ainsi mettre à jour un seul composant ne nécessite pas de reconstruire l'ensemble de ces paquets avec la tonne de mises à jour que cela implique pour les utilisateurs. Le découpage des SRPM suit celui du projet officiel pour avoir du sens en terme de dépendances. Cependant le nombre de sous-paquets générés ne change pas.

Outre cela, cette mise à niveau permet l'usage du format PDF 1.7 par défaut. Changer l'échelle des polices au-delà de 2048 points génère une erreur propre plutôt qu'un problème silencieux en arrière plan. LuaTeX comme pdfTeX sont améliorés.

Le paquet d'intégration avec la bibliothèque Qt5 pour LibreOffice est supprimé, les environnements de bureaux utilisant Qt6 maintenant.

Gestion du matériel

Pour les systèmes Aarch64 avec un EFI, la sélection du device tree sera automatique au démarrage de l'image Live pour les ordinateurs portables Windows ARM. En effet une problématique dans le monde ARM, contrairement à l'univers PC avec l'architecture x86, la table ACPI et les protocoles avec une énumération des périphériques dynamiques tels que USB / PCIe ne suffisent pas à décrire le matériel de manière suffisamment complète pour démarrer la machine. Il est nécessaire pour cela de fournir un fichier additionnel, le device tree, qui est en général maintenu au sein du noyau Linux.

Et dans le cadre d'une image Live, il faut une image unique qui peut démarrer sur n'importe quelle machine. Pour les ordinateurs portables ARM, jusqu'ici il était nécessaire de personnaliser l'image Live à la main pour permettre un tel démarrage afin de fournir et de sélectionner le bon device tree à employer. La nouvelle procédure rend l'ensemble bien plus simple pour les utilisateurs. Cela repose sur une image noyau unifiée sans initrd mais avec systemd-stub et hardware-id pour identifier le bon device tree pour cette machine. Ainsi un initrd adapté et la ligne de commande pour charger le noyau Linux final seront générés et fournis à GRUB pour lancer le démarrage avec l'ensemble des informations nécessaires.

Internationalisation

L'outil d'aide à la saisie IBus évolue à la version 1.5.34. Il prend en charge le protocole des méthodes de saisie de Wayland ce qui permet de tirer profit de deux changements pour les environnements Wayland non basés sur GNOME (qui ne le prend pas en charge à ce jour). Il peut en effet automatiquement supprimer le texte environnant suivant le contexte, comme par exemple retirer un caractère ayant servi à la composition d'une autre ou de corriger le placement de la ponctuation dans un texte. Il peut également adapter la couleur du texte et du surlignage lors de la pré-édition pendant l'aide à la saisie en fonction du contexte (comme la prédiction complète d'un mot, la détection d'une faute d'orthographe, etc.). Enfin les annotations des émojis sont affichées dans la table de sélection.

Le module Ibus pour la transcription vocale est mis à jour à la version 0.7.0 qui propose un module pour utiliser la famille de modèles Whisper d'OpenAI en plus du modèle Vosk déjà employé. Il est possible de choisir le modèle souhaité dont les variantes exécutées en local ou ceux disponibles en ligne via la plateforme Hugging Face. Le module essaye de trouver automatiquement le modèle adapté à la langue employée mais il reste possible de définir cela manuellement en cas de besoin. Normalement la qualité du rendu de la transcription vocale devrait être améliorée tout en ayant la flexibilité dans le choix du modèle.

Administration système

Les images Fedora Cloud n'ont plus une partition /boot dédiée mais utilisent un sous-volume btrfs à la place. Cela ne s'appliquera cependant pas aux images UEFI-UKI ou pour l'architecture s390x à cause des limitations de ces systèmes. L'objectif est de réduire la taille de l'image initiale car il n'est plus nécessaire de fournir de l'espace libre dédié à cette partition. Et par conséquent, cela permet au reste du système de pouvoir utiliser plus d'espace librement sans devoir tenir compte de cette dite réserve.

L'émulateur QEMU n'aura plus de paquets compatibles avec l'architecture 32 bits i686 car cette architecture n'est plus maintenue par le projet officiel. Par ailleurs cette architecture posait quelques soucis de maintenance par le passé avec des échecs de compilation à gérer pour un paquet très peu utilisé sur de tels systèmes. Mais exécuter un système 32 bits depuis un QEMU 64 bits reste évidemment toujours possible.

Le gestionnaire de paquets nix est introduit dans Fedora Linux. Ce gestionnaire de paquets connu pour être celui de NixOS peut en effet être utilisé sur d'autres environnements Unix sans problèmes ce qui permet ici de bénéficier ou de contribuer à son écosystème de paquets pour ceux qui le souhaitent. Il est possible de s'en servir au niveau système (mode multi-utilisateur) ou pour un utilisateur spécifique. Cependant le projet Fedora ne souhaite pas s'en servir comme gestionnaire de paquets officiel, de la même façon que npm ou pip peuvent être utilisés depuis Fedora Linux pour récupérer des utilitaires JavaScript ou Python sans utiliser dnf.

Le gestionnaire de paquets Kubernetes Helm utilise la version 4 dorénavant tandis que la version 3 reste disponible avec le paquet helm3. En effet cette nouvelle version brise la compatibilité ascendante et comme il est très employé dans un contexte d'intégration continue ou de gestion de systèmes de conteneurs, la migration peut prendre du temps d'où la conservation de l'ancienne version qui sera retirée probablement pour Fedora Linux 45.

En terme de nouveautés, il prend en charge des extensions écrites en WebAssembly, il prend en charge également les OCI digest ou des arguments en format JSON. Son architecture a été revue pour utiliser des paquets versionnés et restructurer l'empaquetage. Le format Chart v3 est également pris en charge.

Le gestionnaire de bases de données MariaDB passe par défaut de la version 10.11 à la version 11.8. La version 11.8 était déjà proposée dans les dépôts, elle remplace juste la version 10.11 en tant que version de base. Cette dernière reste disponible via le paquet mariadb10.11.

L'outil Ansible est mis à jour à sa 13e version. Depuis la précédente version proposée dans Fedora Linux, Ansible 11, il fournit majoritairement des améliorations de sécurité et une plus grande robustesse dans le moteur de templates. De nombreux comportements invalides ignorés auparavant peuvent générer des erreurs et doivent être corrigés. D'ailleurs la gestion des erreurs a été également améliorée. Les modules plus spécifiques ont été mis à jour ce qui peut nécessiter une adaptation des playbooks existants.

Les paquets pour le gestionnaire de bases de données MySQL avec le nom community-mysql sont supprimés. L'objectif est de simplifier la maintenance et de rendre la situation plus claire pour les utilisateurs qui peuvent se référer uniquement aux paquets nommés mysql et dérivés.

Les paquets rust-coreutils et rust-nu qui vont respectivement de la version 0.0.27 à 0.5.x et de la version 0.99.1 à 0.109.2. Cette implémentation des outils de base de système en Rust gagnent en popularité et en maturité, étant utilisés par défaut dans Ubuntu maintenant. Cette version apporte une meilleure compatibilité avec les outils GNU. Son évolution très rapide jusqu'alors gênait les possibilités de mettre à jour ses dépendances telles que le shell Nu qui peut maintenant être mis à jour plus souvent. Les utilitaires GNU restent toujours les versions de référence dans Fedora Linux.

Développement

La chaine de compilation GNU progresse avec GCC 16.1, binutils 2.46, glibc 2.43 et gdb 17.1.

Le compilateur GCC a beaucoup travaillé sur la prise en charge initiale de la nouvelle version du langage C++26, mais des améliorations notables concernant C++23 sont également de la partie. Concernant le langage Ada, des extensions GNAT sont ajoutées et qui diffèrent du standard pour simplifier l'écriture du code ou se rapprocher des autres langages comme de nouvelles méthodes de constructions et de finalisation des objets. Côté matériel, les derniers processeurs Intel ont leurs optimisations spécifiques disponibles pour ceux qui le souhaitent tandis que le surcoût d'utiliser une carte graphique AMD avec les technologies OpenMP et OpenACC a été drastiquement réduit. OpenMP peut utiliser l'allocateur mémoire de l'API CUDA pour les cartes graphiques Nvidia afin d'améliorer les performances.

Les utilitaires binutils, outre la prise en charge de matériel plus moderne, il gère le format SFrame version 3 ce qui permet notamment de charger des sections .text de plus de 2 Gio.

La bibliothèque C glibc quant à elle, s'occupe d'améliorer la prise en charge de la version du langage C23. Elle peut gérer des caractères Unicode 17.0 et optimise certaines fonctions mathématiques comme acosh, asinh ou atanh pour les fonctions trigonométriques et la famille de fonctions fma pour le calcul de fonctions affines. Elle prend en charge les nouveaux appels systèmes mseal et openat2, le premier permettant de protéger une zone mémoire d'un changement de permissions ou de taille ultérieurement tandis que le second ajoute de nombreuses options supplémentaires à openat pour l'ouverture de fichiers.

Enfin le débogueur GNU peut gérer sur des architecture x86_64 une shadow stack avec des pointeurs 32 bits. Dans le protocole Debugger Adapter il accepte les requêtes pour la complétion d'une commande. Il devient plus simple de changer le style des couleurs de la sortie dans le terminal en fonction de ses préférences. Il peut également tirer parti des espaces de nom de l'éditeur de liens pour afficher cette information lors du débogage, notamment lors de l'affichage des informations concernant les bibliothèques partagées utilisées par le programme en cours d'analyse.

La chaine de compilation LLVM version 22 est proposée. Comme souvent l'alter égo de la chaine de compilation GNU n'est pas en reste avec la prise en charge initiale de la future version du langage C nommée C2y à ce jour. Plus d'optimisations matérielles peuvent être exploitées avec les expressions constantes de C++. comme les instructions SSE, AVX, et AVX-512. De même plus de micro architectures sont prises en charge pour des optimisations supplémentaires pour le matériel récent.

L'outil de configuration de l'environnement de compilation CMake passe à la version 4.2. Cela entraîne une rupture de compatibilité pour les projets ayant besoin de la version 3.5 ou inférieure. Outre l'évolution de son File API, il prend en charge la copie d'arborescence, via l'option -E copy_if_newer, basée sur la valeur de la date du dernier changement plutôt que celui de la différence de contenu pour être plus rapide. Une nouvelle option de ligne de commande --project-file permet d'utiliser un fichier alternatif à CMakeLists.txt à des fins de développement pour des tests temporaires. Le préfixe LINKER: peut être ajouté à différentes variables et commandes. Enfin, la variable CMAKE_FIND_REQUIRED peut être employée pour forcer toutes les commandes de recherche d'un fichier, d'une bibliothèque ou d'un programme d'émettre une erreur par défaut s'il n'est pas trouvé, au lieu de devoir le préciser à chaque commande. Le projet Fedora a dû proposer beaucoup de correctifs aux paquets compilés avec CMake pour permettre leur bonne compilation.

La bibliothèque C++ Boost passe à la vitesse supérieure avec la version 1.90. C'est la première mise à jour de ce composant depuis Fedora Linux 40, entre temps de nombreuses sous-bibliothèques sont apparues comme Charconv, Cobalt, Hash2, MQTT5, OpenMethod, Parser, Redis et Scope. La plupart des sous-bibliothèques ne prennent plus en charge C++03 et nécessitent au moins C++11 voire C++14 maintenant ce qui peut impacter la compatibilité des vieux projets.

Le langage de programmation Ruby prend de la valeur avec sa version 4.0 carats. Les opérateurs logiques binaires utilisés dans des conditions sont dorénavant compatibles en multi-lignes pour simplifier la lecture. En cas d'erreurs concernant les arguments pour appeler une fonction, un extrait du code de l'appelant et de l'appelé est affiché pour simplifier le débogage. Concernant les compilateurs juste à temps proposés, RJIT est retiré tandis que ZJIT est introduit. Il n'est pas encore recommandé de se servir de ce dernier en production, l'objectif est d'en faire une référence pour la prochaine version, quand il sera plus performant que la référence actuelle YJIT. Enfin Ractor comme mécanisme d'exécution parallèle a vu ses performances améliorées en ayant moins de données partagées et en utilisant moins de verrous globaux, l'objectif est — pour lui aussi — d'en retirer son statut expérimental pour la prochaine version.

Le paquet ruby-build est d'ailleurs scindé en plusieurs sous paquets pour rendre son utilisation plus modulaire. Ainsi au lieu de tirer l'ensemble des composants pour permettre de compiler n'importe quelle implémentation de Ruby, uniquement ceux nécessaires peuvent être téléchargés et installés ce qui peut éviter de devoir télécharger la chaine de compilation Rust ou OpenJDK et ainsi passer de 400 Mio de paquets à obtenir à quelques Mio seulement. Donc maintenant les dépendances essentielles pour cela sont regroupées dans le paquet ruby-build-core, si l'objectif est de compiler JRuby, le paquet ruby-build-jruby peut être installé, pour PicoRuby c'est ruby-build-picoruby, etc.

Le langage Go saute vers sa version 1.26. Le langage permet maintenant de spécifier une expression comme valeur par défaut pour une nouvelle variable en construction, comme par exemple une référence vers un champ JSON à parser. Il permet aussi de spécifier des contraintes de type pour des paramètres d'une fonction, qui réfère à un type générique, qui se réfère à lui même. Niveau outillage, la commande go fix permet de facilement porter un code existant vers une construction plus moderne à l'aide de moderniseurs qu'il fournit. Le ramasse miettes Green Tea est activé par défaut et doit fournir une réduction de son impact de 10 à 40% dans des programmes classiques. Pour les architectures x86_64, par défaut l'adresse mémoire du tas est initialisée à une adresse aléatoire au lancement de l'application pour réduire le risque d'attaques. Les appels de code C sont aussi 30% plus rapides.

Le langage PHP passe à la version 8.5. Parmi les nouveautés, il propose une nouvelle classe URI pour faciliter la manipulation des liens, il introduit également le concept de pipe avec |> pour enchainer les opérations sans nécessiter de variables intermédiaires ce qui simplifie l'écriture et la relecture du code. Il devient également possible de cloner un objet tout en éditant des propriétés à la volée ce qui est particulièrement utile pour les objets avec des champs en lecture seule. Une fonction peut ajouter la propriété #[\NoDiscard] pour générer une alerte si un appelant ne récupère pas la valeur de retour de cette fonction, ce qui permet d'améliorer la conception et l'utilisation des APIs. Les erreurs fatales fournissent aussi une trace d'appel pour mieux déboguer le programme. Et bien d'autres changements encore.

Le langage Haskell devient plus fonctionnel avec son compilateur GHC version 9.10 et sa suite de paquets Stackage 24. Le langage dispose de quelques petites améliorations comme la possibilité pour la boucle forall d'avoir le qualificatif visible afin de spécifier le type de l'objet employé dans la boucle sans inférence. Ou encore de déprécier une instance de classe afin de générer une alerte en cas d'utilisation. Sinon le compilateur dispose de la possibilité pour le backend JavaScript de se lier à du code C grâce à l'usage de WebAssembly, tandis que le backend WebAssembly permet d'appeler du code JavaScript et inversement du code JavaScript qui peut appeler du code Haskell.

Le projet Fedora en profite pour supprimer les paquets de profilage ghc-*-prof pour les architectures non x86_64 et aarch64, sauf pour la bibliothèque standard, car leur usage était probablement rare et le coût de maintenance trop important pour les empaqueteurs.

La boîte à outils web pour Python nommé Django serpente à la version 6. Le changement majeur est l'introduction de la prise en charge interne du Content Security Policy pour facilement bloquer les attaques par injection de contenu comme XSS. Il faut déclarer dans ce cas les ressources externes, comme les scripts ou images, auxquelles le navigateur peut accéder et bloquer ainsi les autres. Il intègre aussi la gestion des templates partiels qui étaient auparavant dans un module externe. Il propose également le concept de tâche pour exécuter des actions potentiellement longues en arrière plan en dehors du cycle de requête-réponse HTTP tel que l'envoi d'un courriel suite à un appel particulier. Enfin il adopte l'usage de l'API Python moderne pour la gestion des courriels. Cette version présente de nombreuses incompatibilités, l'usage de Django 5 reste possible par l'installation du paquet python3-django5.

Des paquets nodejsXX-bin et nodejsXX-npm-bin sont fournis pour créer les fichiers /usr/bin/node et /usr/bin/npm sans nom de versions qui pointent vers la version voulue par l'utilisateur. Ils ne peuvent pas être installés en parallèle ce qui permet de garantir l'unicité de ces fichiers dans un système. Cela signifie qu'il n'y a plus vraiment de version de NodeJS de référence dans Fedora Linux et qu'il est aisé de passer d'une version à une autre selon ses besoins. Pour les mainteneurs, c'est plus facile également de gérer les changements de versions car il n'y a pas la question de gérer la transition d'une version de référence à une autre.

Cette propriété signifie également que passer d'une version à une autre nécessite d'utiliser la commande dnf swap. Par exemple : dnf swap --allowerasing nodejs24-bin nodejs22-bin

La bibliothèque rust-bindgen pour lier du code Rust avec du code C ou C++ est empaquetée à la version 0.72. Avant les versions de 0.68 à 0.72 étaient proposées, mais la nouvelle version LLVM 22 décrite plus haut casse la compatibilité pour représenter l'AST ce qui rend ces anciennes versions non compatibles. Cela a impliqué des adaptations pour les dépendances impactées.

La bibliothèque d'édition des métadonnées des fichiers audio taglib passe à la version 2.0. Cette version ne préserve pas la compatibilité de son ABI et API ce qui a nécessité une adaptation pour ses dépendances comme Ardour et Easytag. Beaucoup de fonctions obsolètes ont été supprimées pour avoir une API plus propre. Le code a été modernisé avec beaucoup de correctifs et un usage de C++17. La prise en charge des propriétés des formats MP4 et RIFF a été également étendue.

Le parseur et moteur de rendu de CommonMark cmark progresse vers la version 0.31.

La machine virtuelle Java OpenJDK 21 n'est plus proposée dans les dépôts. Cela permet de concentrer les ressources sur OpenJDK 25 et 26 qui sont plus utilisées. Ce temps économisé peut être alloué dans la finition de la compatibilité avec Eclipse Temurins.

Le paquet python-mock a été supprimé des dépôts. Son retrait prochain avait été annoncé avec Fedora 34 mais de nombreux paquets en avaient encore besoin jusqu'ici.

Projet Fedora

Les paquets avec des fichiers identiques utilisent des liens physiques par défaut au sein du répertoire /usr. Notamment certains paquets Python peuvent avoir des contenus générés automatiquement qui sont dupliqués avec la macro %__os_install_post_python. Mais la manière de faire n'était pas toujours cohérente entre les paquets et des effets de bord existaient car il pouvait y avoir une différence de date d'édition de fichiers entre deux liens physiques ce qui nuisait à la reproductibilité de la génération des paquets. Maintenant cela est géré de manière uniforme via la macro %__os_install_post qui effectue cette tâche pour tous les fichiers dans %{buildroot}%{_prefix}, que les fichiers soient dans le même paquet ou sous-paquet. Uniquement ce répertoire est pris en compte car les fichiers en son sein sont en général en lecture seule ce qui évite les problèmes liées à l'édition ultérieure du contenu. Un autre aspect positif est une légère réduction de la taille de certains paquets et que différents utilitaires de recherche ou de sauvegarde des fichiers peuvent éviter de parcourir inutilement plusieurs fois le même contenu.

Les systèmes atomiques ne fournissent plus de bibliothèques et de binaires FUSE 2. Les paquets fuse et fuse-libs sont retirés de l'image de base pour permettre l'usage exclusif de FUSE 3, FUSE 2 n'étant plus maintenu. Ces paquets étaient maintenus depuis Fedora Linux 40 car le format AppImage s'en servait dans la première version de son format mais l'ajout d'une seconde version qui exploite FUSE 3 permet de s'en affranchir.

Pour les images Kinoite et Kinoite Mobile, cela signifie que les backends EncFS et CryFS ne sont plus accessibles, si vous êtes concernés vous pouvez les convertir avant ou alors installer les paquets fuse-encfs et cryfs avec rpm-ostree.

Cela ne concerne pas pour l'instant les autres versions de Fedora Linux qui ont un usage plus général et qui peuvent très facilement l'installer en cas de besoin pour ceux qui le souhaitent. Les systèmes atomiques sont quant à eux orientés pour des systèmes minimaux en lecture seule où cet utilitaire n'est plus indispensable par défaut comme expliqué.

Ces systèmes bureautiques atomiques ne prennent plus en charge les règles obsolètes pkla polkit. Les autres systèmes atomiques de Fedora avaient déjà supprimé par défaut ces règles de leur image de base car c'est un format obsolète qui est d'ailleurs peu à peu retiré des autres distributions Linux telles qu'Ubuntu ou Debian.

Les variantes non atomiques ne sont pas concernées à ce stade pour la même raison que le changement précédent, d'autres paquets peuvent en dépendre ce qui rend la suppression totale définitive difficile à ce jour. Les systèmes atomiques n'ont plus de tels composants dans l'image de base ce qui permet une telle transition.

Packit remplace Fedora CI et Zuul pour démarrer les instances d'intégration continue pour compiler et exécuter les tests des paquets après un pull request. En effet le premier est développé par Red Hat et est plutôt bien maintenu avec plus de fonctionnalités que les seconds qui n'avaient pas assez de personnes pour s'en occuper et fournir une bonne stabilité. Cela permet de simplifier la gestion de cette partie de l'infrastructure en se concentrant sur l'intégration plutôt que le développement. Il offre par exemple la possibilité de ré-exécuter certains tests seulement ou d'utiliser des étiquettes associées à une tâche pour définir quels tests doivent être exécutés ou non, afin de gagner du temps lors du développement d'un paquet. Il fournit de fait une interface unique pouvant aller de dist-gist en passant par Koji et Bodhi pour ces différentes tâches. Il est également indépendant de la forge git employée grâce à une API unifiée. À ce jour Gitlab et Pagure sont gérées et Forgejo sera ajoutée plus tard, qui sera à priori la future forge logicielle de Fedora ce qui facilitera la transition à ce moment là.

Koji ne prend plus en charge le service distant Red Hat Image Builder Service, uniquement les instances locales peuvent être utilisées. En effet depuis la version précédente de Fedora Linux, toutes les images peuvent être produites localement. Fedora IoT et Minimal étaient construites via l'infrastructure Red Hat Image Builder, Koji ne servant que d'orchestrateur côté Fedora. Cela posait quelques soucis dont la possibilité d'intervenir en cas de problèmes mais aussi le fait qu'il était impossible de geler les changements de l'infrastructure aux moments adéquats pour l'élaboration des nouvelles images. En plus de s'affranchir du service de Red Hat, cela autorise aussi de supprimer le plugin Koji qui permettait une telle opération. Il devient également possible de réallouer les ressources matérielles associées pour d'autres tâches.

Les labels des images pour conteneurs passent à org.opencontainers.image.title et org.opencontainers.image.licenses pour suivre la spécification OpenContainers. Cela simplifiera l'outillage pour récupérer cette information de manière générique en ayant une nomenclature standard pour toutes les images.

Par ailleurs CMake utilisera le générateur ninja au lieu de make par défaut pour compiler un projet. En effet CMake permet d'utiliser les deux en fonctions des préférences, avec la mise à niveau de CMake décrite plus haut, la prise en charge de ninja est encore meilleure ce qui le rend plus intéressant. Ninja est plus moderne et rapide pour effectuer la compilation d'un projet ce qui est intéressant pour le projet Fedora qui en compile beaucoup. Il prend également mieux en compte le concept récemment introduit des modules C++. C'était d'ailleurs déjà le choix effectué manuellement par certains paquets, maintenant tous les utilisateurs de la macro cmake en bénéficieront par défaut.

Les paquets autour du langage R ont de nouvelles macros et une meilleure uniformisation des bonnes pratiques pour simplifier leur maintenance. Cela représente 400 paquets dans la distribution qui avaient jusqu'ici une gestion assez artisanale et demandait beaucoup de temps pour gérer des situations similaires. De nouvelles macros dédiées ont été ajoutées dans R-rpm-macros tandis que les macros R-srpm-macros ont été ajoutées à la config globale redhat-rpm-config pour permettre leur réutilisation.

Ces macros simplifient beaucoup la maintenance, maintenant la génération de la version et des URLs des projets empaquetés sont gérés de manière uniforme. De même, la procédure d'installation et de la vérification des fichiers est faite de manière identique. Enfin, cela permet de rendre ces paquets reproductibles également.

La communauté francophone

L'association

Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.

Nous lançons donc un appel à nous rejoindre afin de nous aider.

L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.

Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

• Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
• Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
• Concevoir des goodies ;
• Organiser des évènements type Rencontres Fedora dans votre ville.

Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.

Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuelles chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l'avons mis en place en visioconférence sur Jitsi.

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.

Le moins que l'on puisse dire, c'est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège, Sylvain Réault et les autres contributeurs et relecteurs pour leurs contributions.

La synchronisation du travail se passe sur le forum.

Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.

Comment se procurer Fedora Linux 44 ?

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

Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.

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

De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 44.

En ce mardi 28 octobre, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 43.

Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• La communauté francophone
  • L'association
  • La documentation
• Comment se procurer Fedora Linux 43 ?

Expérience utilisateur

L'environnement de bureau GNOME est proposé dans sa version 49. Cette version apporte comme d'habitude de nombreux changements.
Tout d'abord l'application Showtime remplace Totem en guise de lecteur vidéo par défaut. Basée sur la bibliothèque GTK4 et libadwaita, elle reprend les canons esthétiques minimalistes des applications GNOME. L'interface s’efface derrière la vidéo, n'affichant que les fonctions de base essentielles.

De même l'application pour afficher les documents notamment au format PDF passe de Evince à Papers. De la même manière que précédemment, elle utilise la nouvelle pile logicielle plus moderne, cela permet de refaire le visuel de l'application et d'améliorer dans le même temps les performances. La signature numérique des documents est aussi mieux intégrée de même que les annotations des documents.

L'application de calendrier a eu une amélioration de son accessibilité avec un focus important sur la navigation exclusive au clavier, ce qui a nécessité une refonte de l'interface. L'interface s'adapte en fonction de la taille de l'écran avec notamment la barre latérale qui peut être masquée. Il est également possible d'exporter des événements dans un fichier ICS.

Le navigateur Web bénéficie de nombreuses améliorations comme un bloqueur de publicités plus efficace avec plus de listes de blocage disponibles. La recherche dans la page est plus complète avec la prise en compte de la casse ou de la recherche de mots entiers uniquement. L'édition des marques pages, ainsi que le menu de sécurité pour la gestion des mots de passes ou des cartes de sécurité, ont été remaniés pour être plus simples.

La boutique logicielle bénéficie d'une amélioration significative de ses performances, ce qui était son principal point faible en partie à cause du volume de données à gérer pour les différentes applications disponibles provenant des Flatpak. La boutique consomme moins de mémoire, navigue plus rapidement d'une application à une autre et effectue des recherches efficacement.

La fonctionnalité de bureau distant s'améliore avec la prise en charge des entrées multipoints pour ceux utilisant un écran tactile. De plus le curseur de souris peut fonctionner avec un positionnement relatif ce qui était nécessaire pour quelques applications ou jeux vidéo. Ceux qui le souhaitent peuvent ajouter des écrans virtuels pour une telle session même s'il n'y a pas d'écrans physiques supplémentaires.

De manière plus générale, l'écran de verrouillage permet de contrôler basiquement les applications multimédia, en particulier pour la musique. Il est d'ailleurs possible d'arrêter ou de redémarrer la machine depuis cet écran de verrouillage en activant l'option idoine avec la commande gsettings set org.gnome.desktop.screensaver restart-enabled true. Le bouton Ne pas déranger passe de la zone de notifications au menu principal de GNOME pour une meilleure cohérence de l'interface.

Enfin de nouveaux fonds d'écran sont proposés afin d'exploiter les nouvelles capacités des écrans HDR et l'espace de couleur Display P3 qui sont pris en charge sur les machines compatibles. Capacités HDR qui ont été améliorées par ailleurs avec de nouveaux paramètres pour gérer finement la luminosité de ces types d'écran.

GNOME fonctionnera uniquement en tant que session Wayland, les paquets liés à GNOME pour session X11 sont supprimés. Le projet GNOME a décalé cette décision pour sa prochaine version numérotée 50, mais Fedora maintient le cap car la qualité de ces sessions n'est pas aussi bonne que Wayland faute de tests et de maintenance de la part du projet depuis de nombreuses années. Grâce à XWayland, GNOME reste en capacité d'afficher et de gérer les applications (de plus en plus rares) reposant uniquement sur X11. Cela clôt en un sens la transition vers Wayland pour GNOME entamée il y a 9 ans déjà avec Fedora 25.

Tous les Spins disposent par défaut de la nouvelle interface web d'Anaconda. Fedora Linux 42 ne l'avait proposée que pour Fedora Workstation, en partie parce que certaines options ont dû être ajoutées pour supporter les Spins. En effet, sous GNOME, une partie de la configuration est faite après l'installation avec l'application GNOME Initial Setup. Par conséquent les spins pourront en plus configurer depuis Anaconda la date et l'heure, le compte utilisateur et le nom de la machine. De même, la configuration de la disposition clavier est gérée de manière légèrement différente. Enfin, l'interface n'est pas forcément affichée par une session de Firefox mais peut l'être via le navigateur web fourni par l'environnement en question.

Sur les machines x86_64 compatibles UEFI, Anaconda ne permettra plus d'installer Fedora si le format de partitionnement est basé sur MBR au lieu de GPT. Si la norme UEFI autorise une telle configuration, en réalité sa prise en charge correcte dépend des constructeurs et n'est pas bien testée notamment par l'équipe de Fedora ce qui rend une telle configuration peu fiable. De plus, le chargeur de démarrage GRUB2 suppose déjà qu'un système UEFI implique une table de partitions GPT. Cela a été maintenu par Fedora notamment pour permettre son utilisation dans le service cloud AWS qui ne proposait que de tels systèmes à une époque. Mais cette limitation n'a plus lieu d'être et sa suppression simplifie le test et réduit le risque de crashs au moment de l'installation. Cela ne concerne pas les autres architectures comme ARM car leur implémentation repose plus souvent sur MBR et est mieux gérée.

L'installateur Anaconda utilise le gestionnaire de paquet DNF dans sa 5e version dorénavant. Cela améliore la vitesse des opérations à l'installation de Fedora et uniformise la gestion des paquets au sein de Fedora en simplifiant aussi les tests de la distribution.

Fin de support de la modularité des paquets RPM dans l'installateur Anaconda. Les modules ont disparu dans Fedora depuis Fedora Linux 39, ce changement devenait nécessaire avec la non prise en charge des modules par DNF 5 qui est utilisé maintenant par Anaconda comme expliqué précédemment. Cela améliore aussi la maintenance d'Anaconda et de sa documentation en supprimant cette spécificité qui n'est plus utilisée.

Activation de la mise à jour automatique du système pour la variante Fedora Kinoite. Grâce au système atomique, la mise à jour se fait en arrière plan et est appliquée au prochain redémarrage. La fiabilité de l'opération avec la possibilité de revenir à l'état précédent autorise une mise à jour automatique sans trop de problèmes pour simplifier la vie de l'utilisateur et améliorer la sécurité. Les mises à jour des firmware ne sont pas concernées pour des raisons de fiabilité. La mise à jour se fait par défaut de manière hebdomadaire et une notification pour inviter à redémarrer est affichée quand c'est pertinent. Cette fonctionnalité peut être coupée et la fréquence des mises à jour reste configurable.

La police d'affichage d'émojis Noto Color Emoji utilise son nouveau format basé sur COLRv1 pour améliorer le rendu. Le rendu est meilleur car les images sont vectorielles et non sous forme d'images bitmap qui sont moins jolies quand la taille d'affichage augmente. Le tout en prenant moins d'espace disque.

Le fichier initrd utilisé lors du démarrage est compressé avec zstd pour un démarrage plus rapide du système et une taille d'installation plus petite. Cela remplace la dépendance au binaire xz utilisé jusqu'alors, les tests montrent une baisse de la taille d'installation de quelques méga octets pour un temps de démarrage réduit de quelques secondes en moins.

Gestion du matériel

La taille de la partition /boot augmente de 1 Gio à 2 Gio par défaut. En effet la taille des firmwares, des initrd, du noyau, etc. ne cessent d'augmenter alors que la partition est restée à 1 Gio depuis 2016. Cela permet de réduire le risque de manquer de place dans un futur proche pour les nouveaux systèmes.

Prise en charge de la technologie Intel TDX pour exécuter des machines virtuelles avec une plus grande isolation mémoire depuis Fedora Linux. Pour les machines compatibles, cela signifie que chaque machine virtuelle tourne dans un espace mémoire dédié qui est chiffré ce qui apporte des garanties de sécurité et d'intégrité des données pour le système virtualisé.

Mise à jour de Greenboot vers la réimplémentation en Rust. L'objectif de ce composant est de fournir une vérification du système au démarrage et de redémarrer vers un état précédent du système en cas de défaut constaté ce qui est possible dans un système atomique et améliore l'expérience utilisateur en cas de mise à jour défectueuse. L'utilisateur a par ailleurs la possibilité d'ajouter ses propres tests. La précédente implémentation était en Bash et ne proposait que la prise en charge des systèmes basés sur RPM OSTree. Maintenant il peut gérer les systèmes reposant sur bootc qui est de plus en plus employé.

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. Jusqu'ici une police sans-serif était utilisée par défaut ce qui n'était pas idéal car les contextes d'usage sont différents et cela pouvait donner lieu à des comportement imprévisibles suivant les polices installées sur le système. Cela concerne notamment les langues suivantes : l'arabe, l'hébreu, le thaï, le perse, l'hindi, le khmer, etc.

Administration système

Le gestionnaire de paquets RPM passe à la version 6.0. Mais les paquets fournis par le projet Fedora utilisent encore le format de la 4e version. Cette version se focalise sur une amélioration de sécurité, par exemple les clés OpenPGP affichent la version complète de l'id de la clé si l'empreinte numérique n'existe pas. Il est possible de fournir plusieurs signatures à un même paquet permettant d'utiliser des clés différentes suivant la provenance et les objectifs. La construction du paquet peut générer automatiquement la signature ce qui est intéressant dans le cadre de l'empaquetage local. Les clés OpenPGP version 6 sont prises en charge de même que les algorithmes dits post quantiques à base de courbes elliptiques. Il est également possible d'utiliser Sequoia-sq au lieu de GnuPG. Les paquets générés avec la 3e version ne sont cependant plus exploitables.

Réduction du nombre de règles SELinux dontaudit liés au type unlabeled_t. L'objectif de ces règles c'est souvent de réduire le nombre de rapports d'accès anormaux qui sont des faux positifs ou des accès bénins effectués par des applications mal écrites. Cette avalanche de notifications serait contre productive mais cacher ces accès sous le tapis ne permet pas de corriger ces comportements problématiques et complexifie le débogage. L'objectif est de désactiver seulement certaines de ces règles de la politique et non de les supprimer entièrement. Ainsi si le nouveau comportement vous pose problème, vous pouvez exécuter la commande # setsebool -P dontaudit_unlabeled_files 1 pour rétablir le comportement précédent.

Le paquet gnupg2 pour fournir l'outil de chiffrement est dorénavant découpé en plusieurs sous paquets. Cela permet de réduire la taille du système par défaut car uniquement les paquets nécessaires seront installés par défaut, laissant de côté les binaires plus optionnels. L'autre bénéfice est de simplifier le remplacement par Sequoia-PGP car il nécessite la présence de certains binaires de GnuPG mais en remplace d'autres ce qui n'était pas possible de faire avec un paquet unique. Les installations existantes installeront tous les sous paquets par défaut pour éviter de casser les systèmes existants.

Le filtre d'impression Foomatic-rip rejette les valeurs inconnues. En effet il est utilisé pour construire des commandes shell, PostScript ou Perl qui sont ensuite exécutées avant d'envoyer la tâche à l'impression via les options FoomaticRIPCommandLine, FoomaticRIPCommandLinePDF et FoomaticRIPOptionSettings. Cette flexibilité permet d'écrire ou de modifier facilement le pilote de l'imprimante en question mais est source de vulnérabilités de sécurité aussi. Pour limiter les risques, par défaut aucune valeur pour ces options ne sont autorisées. L'utilisateur doit exécuter foomatic-hash une fois pour vérifier la validité des options et s'assurer qu'elles ne font rien de problématiques et déplacer le dit fichier dans /etc/foomatic/hashes.d pour autoriser leur utilisation. Cela ne concerne à priori que des vieux pilotes d'imprimantes et une partie de ceux fournis par CUPS ont déjà les validations nécessaires. D'autres devraient venir progressivement. Les pilotes d'imprimantes déjà installés au niveau du système seront aussi automatiquement validés après une mise à niveau vers Fedora Linux 43. À cause de la flexibilité de la méthode d'origine, corriger ou détecter tous les comportements problématiques automatiquement n'est pas possible.

Le projet 389 Directory Server ne permet plus de modifier ses bases de données BerkeleyDB. Les bases de données utilisaient par défaut LMDB depuis Fedora Linux 40 et l'abandon de BerkeleyDB se fera à priori pour Fedora Linux 45. L'objectif est de permettre la lecture des données pour les migrer vers le nouveau format et ainsi forcer les utilisateurs à effectuer la migration avant son abandon total.

Le gestionnaire de base de données PostgreSQL est mis à jour à sa 18e version. Cette version améliore les performances dans le sous-système des entrées-sorties asynchrones et dans l'optimiseur des requêtes. D'ailleurs, la migration d'une base de données vers une version suivante conserve les statistiques de l'optimiseur. Une nouvelle fonction uuidv7() permet de générer un UUID autorisant un tri basé sur un critère temporel. Par défaut les colonnes générées, celles dont le contenu est créé durant une opération de lecture, sont virtuelles et ne résident pas sur le disque. Les B-tree index multi-colonnes peuvent être utilisés plus souvent notamment s'il n'y a pas de contraintes sur les premières clés mais uniquement sur la dernière. Le protocole OAuth peut être utilisé pour s'authentifier dorénavant. Comme d'habitude, les versions 17 et 16 de ce logiciel restent disponibles dans les dépôts autorisant une mise à niveau progressive.

Le gestionnaire de base de données MySQL passe par défaut à la version 8.4. La version 8.4 était déjà proposée dans les dépôts, elle remplace juste la version 8.0 en tant que version de base. Cette dernière reste disponible via le paquet mysql8.0.

Le serveur de courriels Dovecot est mis à jour vers sa version 2.4. ( https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2.4.html ). Cette version change de manière significative la configuration qui nécessite une adaptation. Il est maintenant possible de stopper une commande mail qui prend du temps proprement. Pour l'authentification, les fonctions de hashage SCRAM-SHA-1-PLUS et SCRAM-SHA-256-PLUS sont maintenant disponibles de même que les liaisons de canal TLS. La bibliothèque Lua permet d’interagir avec le client DNS et HTTP fourni par Dovecot.

Le serveur d'application Tomcat est mis à jour vers sa version 10.1. Cela signifie qu'il suit la spécification Jakarta EE 10 ce qui implique un nouvel espace de nom qui passe de javax.* à jakarta.*. À cause de ce changement, la compatibilité ascendante n'est pas garantie et une recompilation des applications web est requise. De même l'API interne de Tomcat a beaucoup changé subtilement ce qui rend la compatibilité binaire impossible à garantir et nécessite une revue pour ceux qui interagissent avec ces APIs. Par défaut les requêtes et réponses Web se font en UTF-8 tandis que les sessions ne sont pas conservées après un redémarrage du serveur. Les fichiers de logs ne seront créés que lorsque du contenu doit être écrit dedans. Enfin les paramètres HTTP en commun entre HTTP 2 et 1.1 seront placés au niveau du connecteur HTTP 1.1 pour permettre à la version 2 d'en hériter et limiter ainsi la duplication des paramètres.

Migration de l'utilitaire de journalisation lastlog à lastlog2. Le premier intérêt de cette migration est de corriger le bogue de l'an 2038 qui n'affecte pas ce dernier. Il peut également utiliser la base de données SQLite 3 pour le stockage. Il utilise aussi des composants PAM pour l'authentification et la sortie est compatible de manière ascendante également. De plus il est légèrement plus performant en augmentant la taille de stockage à partir du nombre d'utilisateurs et non du plus grand id utilisateur dans le lot. Le risque de problèmes de compatibilité devrait être faible. La migration vers le nouveau format sera effectuée automatiquement et des liens symboliques vers les noms des anciens binaires sont créés pour éviter de casser des scripts existants.

L'information PLATFORM_ID dans os-release est supprimée. Cette information a été ajoutée dans le cadre de la modularité, mais avec l'abandon de celle-ci cette ligne n'est plus nécessaire. Ceux qui se basent sur cette information sont invités à changer d'approche.

Développement

La chaine de compilation GNU évolue avec binutils 2.45 et glibc 2.42. Pour binutils, les informations sframe générées par l'assembleur sont maintenant conformes avec la spécification SFrame V2. L'assembleur gère les dernières évolutions des architectures RISC-V, LoongArch et AArch64. Il peut également utiliser les directives .errif et .warnif pour avoir un diagnostic contrôlé par l'utilisateur avec des critères qui sont évalués uniquement à la fin de l'assemblage.

Pour la bibliothèque C glibc, elle prend en charge de nouvelles fonctions mathématiques introduites dans C23 telles que ompoundn, pown, powr, rootn et rsqrt. Elle propose aussi en avance les fonctions valeurs absolues non signées qui seront proposées par la prochaine norme C. Ajout également de la fonction pthread_gettid_np pour connaître l'id d'un thread à partir d'une structure opaque pthread_t. Le cache local dans malloc gagne en performance pour les petites allocations mémoire et peut prendre en charge des blocs à mettre en cache de plus grande taille via l'option glibc.malloc.tcache_max. Le manuel a été particulièrement enrichi pour être plus complet notamment pour les threads, terminaux, systèmes de fichiers, ressources et fonctions mathématiques.

L'éditeur de lien Gold du paquet binutils-gold est considéré comme déprécié et sera supprimé dans une version future. Fedora Linux a déjà quatre éditeurs de liens : ld.bfd, ld.gold, lld et mold. Se débarrasser de l'un d'entre eux qui n'est plus maintenu par le projet GNU n'est pas un problème et doit améliorer à terme la maintenance.

Mise à jour de la chaine de compilation LLVM à sa version 21. Les cartes graphiques AMD voient une amélioration de la prise en charge de ROCm de même qu'un effort pour proposer une bibliothèque C pour GPU. Mais les architectures RISC-V ou cartes graphiques de Nvidia ont également quelques améliorations mineures de ce côté. Le compilateur C CLang optimise l’arithmétique des pointeurs avec le pointeur null et comme souvent le suivi des futurs standards C et C++ se poursuit. Le compilateur fait de meilleurs messages d'erreurs pour les erreurs de compilation.

Côté Fedora, les RPM de ce projet sont compilés avec un profil d'optimisation ce qui devrait significativement améliorer les performances du compilateur maison.

Le langage Python mue à sa version 3.14. Cette version propose des template strings pour étendre les capacités des f-string afin de plus facilement modifier la valeur de la chaîne de caractères à partir d'autres variables. L'évaluation différée des annotations permet de résoudre les annotations de type qui sont cycliques. De plus, un nouveau module concurrent.interpreters fait son apparition pour permettre l'exécution d'interpréteurs Python dans des fils d'exécution uniques pouvant communiquer entre eux, ouvrant la voie à un vrai parallélisme sans renoncer, pour le moment, au fameux verrou principal nommé GIL. Le module compression accueille l'algorithme zstd qui est de plus en plus utilisé dans divers projets libres. Enfin les UUIDs 6, 7 et 8 font leur apparition, permettant de générer des UUIDs respectant différents critères, les deux premiers autorisent un tri temporel quand le dernier est un assemblage de 3 entiers fournis en paramètre. Il y a évidemment d'autres changements améliorant notamment des performances ou rendant les messages d'erreurs plus clairs.

Le langage Go passe à la version 1.25. Il est possible dans cette version d'activer le détecteur de fuites de mémoire à la compilation d'un programme par la commande go build -asan, le rapport sera généré à la fermeture du programme. La commande go vet détecte les appels de fonctions sync.WaitGroup.Add mal placés de même que l'usage de fmt.Sprintf("%s:%d", host, port) pour construire des adresses de connexions qui sont invalides en cas d'usage d'IPv6. Un nouveau ramasse-miettes expérimental fait son apparition, il doit réduire l'impact de ces opérations de 10-40% pour un programme standard qui fait beaucoup d'allocations et de désallocations de petits objets. En terme d'expérimentations, un nouveau module expérimental encoding/json/v2 fait son entrée en matière pour l'encodage et le décodage de JSON, qui doit être plus performant pour le décodage tout en supprimant certaines limitations. Pour les développeurs, un nouveau module runtime/trace.FlightRecorder permet de facilement enregistrer la trace d'événements précis dans le programme dans le contexte de débogage tout en étant léger pour ne pas perturber l'exécution du logiciel par les traces complètes habituellement utilisées. Dans le contexte du débogage, le format DWARF5 pour les informations de débogage peut être exploité ce qui améliore la taille du binaire et le temps de l'édition des liens par ailleurs.

Le langage Perl fourni une réponse brillante avec sa version 5.42. L'accent a été mis pour améliorer les performances dans cette version. Mais en plus de cela, les méthodes peuvent être déclarées avec une visibilité réduite avec l'instruction my method, ces méthodes peuvent être appelées grâce à l'opérateur ->&. Deux nouveaux opérateurs expérimentaux all et any pour vérifier une condition sur l'ensemble, et respectivement aucun, des éléments d'une liste. Un pragma source::encoding peut être apposé sur un fichier source pour détecter les erreurs d'encodage du dit fichier s'il ne correspond pas à celui mentionné. Une classe peut générer automatiquement un setter pour un de ses attributs via l'attribut :writer qui fonctionne de manière analogue à :reader pour le getter.

La boîte à outils Ruby on Rails démarrera voie 8.0. La gestion de certaines dépendances a été améliorée, en effet pour bénéficier de certaines fonctions telles que les Websockets, les jobs ou le cache il était nécessaire d'utiliser au choix MySQL, PostgreSQL ou Redis. Maintenant SQLite s'ajoute à la liste des possibilités et cela passe par de nouvelles couches d'abstractions Solid Cable, Solid Cache et Solid Queue. Fournir des fichiers statiques repose sur Propshaft au lieu de Sprockets, qui est bien plus simple en tirant profit des changements dans le monde Web opérés depuis 15 ans tels que les frameworks JavaScript ou la bonne gestion des petits fichiers avec le protocole HTTP/2 qui permettent de déléguer la gestion de ces problématiques aux frameworks JavaScript directement. Pour finir, elle propose un moyen simple de générer un template basique mais efficace pour la gestion de l'authentification d'une application, en exécutant bin/rails generate authentication vous obtenez un modèle basique pour la session et l'utilisateur avec des contrôleurs pour la session et l'authentification elle même.

La machine virtuelle Java OpenJDK 25 est fournie. Parmi les changements, un effort a été consenti pour améliorer le mécanisme de l'Ahead-of-Time, la mise en cache de la JVM. Il devient en effet plus facile d'exécuter une application simple pour générer la liste des objets et modules nécessaires pour rendre les prochains lancement plus rapides et de même les profils générés pour accélérer l'application seront immédiatement exploités au démarrage pour également accélérer le lancement de l'application. Le système d'enregistrement des événements est étendu avec la possibilité d'enregistrer précisément le temps d'exécution d'une fonction et sa pile d'appels. Il est possible d'appeler d'autres fonctions ou opérations dans un constructeur avant qu'il n'appelle lui même un autre constructeur du même objet ou de sa classe parente ce qui peut simplifier le code en le rendant plus naturel.

L'utilitaire dans l'écosystème Java nommé Maven bénéficie de la version 4 en parallèle de la version 3. La version 4 est accessible via le paquet maven4 depuis les dépôts. Parmi les changements fondamentaux, il y a une séparation entre les besoins de compilation et d'utilisation du fichier pom.xml qui mentionnait dans le détail les informations de compilation ou des dépendances ce qui était rarement utile pour les utilisateurs lors du déploiement. Maintenant le fichier destiné à être distribué ne mentionne plus ces informations superflues. Dans ce contexte, un nouveau type de paquet bom est fourni pour générer une liste de composants nécessaires pour ce logiciel ce qui est un atout dans une optique de traçabilité et de suivi des failles de sécurité par exemple. Pour clarifier la différence entre les modules de Maven et ceux de Java, les modules sont renommés subprojects, d'ailleurs ces sous-projets peuvent déduire des informations du parent comme sa version par exemple ce qui rend inutile de le mentionner à nouveau. Les sous-projets peuvent aussi être découverts au sein du projet évitant le besoin de les déclarer explicitement et systématiquement.

Le compilateur pour le langage Haskell GHC a été mis à jour vers sa version 9.8 et son écosystème Stackage vers la version 23. Le langage fonctionnel dispose des ExtendedLiterals pour préciser le type précis d'un entier défini tel quel dans le code, comme 123#Int8 pour un entier représenté uniquement sur 8 bits. Dans le bas niveau, un logiciel compilé avec -mfma pour permettre l'usage des instructions, qui combinent multiplication et addition (telle que fmaddFloat# x y z qui donne x * y + z) si l'architecture matérielle les supporte ce qui peut améliorer les performances du programme. Il introduit des nouveaux pragmas WARNING et DEPRECATED à des fonctions d'un module pour signaler à un appelant de prêter attention à son utilisation, notamment en cas de suppression planifiée de la dite fonction.

Le langage de programmation fonctionnel Idris dispose d'une mise à jour majeure vers sa 2e version. La version 1 reposait sur Haskell mais il devenait de plus en plus difficile de le générer avec des versions récentes du compilateur GHC. La version 2 est implémentée en Scheme et repose sur la théorie des types quantifiés, ainsi une variable assignée à une quantité 0 est effacée, assignée à une quantité 1 elle est utilisée une seule et unique fois, etc. Ce changement de paradigme rend de nombreux programmes écrits pour Idris 1 incompatibles. De plus le Prelude du langage ne contient que les éléments strictement nécessaires dans la plupart des programmes non triviaux, le reste est relégué dans dans la bibliothèque base.

Le compilateur Free Pascal propose des paquets permettant la compilation croisée avec d'autres architectures. Ce changement facilite la compilation de programmes pour d'autres systèmes sans quitter sa Fedora Linux. Les paquets nécessaires sont de la forme fpc-cross-$CPU et fpc-units-$CPU-$OS où le premier fourni le compilateur en lui même à destination d'une architecture matérielle spécifique quand le second fourni des objets précompilés nécessaires la plupart du temps pour générer un programme pouvant s'exécuter sur le matériel et système considéré. Si vous souhaitez compiler pour du Windows x86 il faudra installer par conséquent les paquets fpc-cross-i386 et fpc-units-i386-win32.

La bibliothèque d'Intel tbb pour paralléliser certaines tâches passe à la version 2022.2.0. Les changements sont relativement mineurs mais à cause de la rupture de compatibilité de l'ABI, les logiciels s'en servant doivent être recompilés pour fonctionner avec cette nouvelle version.

La signature cryptographique des informations de débogage debuginfod est maintenant vérifiée automatiquement du côté du client. Les paquets RPM fournissaient la dite signature depuis Fedora Linux 39, le client comme serveur prenaient en charge la fonctionnalité, il ne manquait plus qu'une configuration adéquate pour permettre ce changement. Cela se fait en éditant le fichier de configuration /etc/debuginfod/elfutils.urls ainsi :

ima:enforcing https://debuginfod.fedoraproject.org ima:ignore

Cela ne le fait que pour les informations de débogage provenant du projet Fedora, pour les autres il faudra activer cela manuellement de manière similaire.
En cas de signature invalide, les fichiers concernés seront rejetés et considérés comme non disponibles ce qui améliore la fiabilité et la sécurité du débogage.

La bibliothèque Rust async-std est considérée comme dépréciée avant une suppression future. Il n'est en effet plus maintenu et il est recommandé de passer à la bibliothèque smol à la place.

La bibliothèque Python python-async-timeout est considéré comme dépréciée avant une suppression future. Cette fonctionnalité est en effet fournie dans la bibliothèque standard depuis Python 3.11 rendant cette bibliothèque obsolète. Cependant une trentaine de paquets s'en servent encore directement rendant sa suppression impossible à ce stade.

Le paquet python-nose a été retiré. Déprécié par Fedora depuis plus de cinq ans et sans maintenant depuis plus longtemps, sa suppression devenait nécessaire avec l'impossibilité de s'en servir avec la dernière version de Python. Les paquets qui en avaient encore besoin ont été corrigés pour s'en passer.

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. Ils étaient dépréciés depuis Fedora Linux 42 car non maintenus.

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. Cela concerne les images Fedora IoT et Minimal qui étaient construites via l'infrastructure de Red Hat, Koji ne servant que d'orchestrateur côté Fedora. Cela posait quelques soucis dont la possibilité d'intervenir en cas de problèmes mais aussi le fait qu'il était impossible de geler les changements de l'infrastructure aux moments adéquats pour l'élaboration des nouvelles images. Le paquet koji-image-builder a été créé pour permettre d'exécuter cette machinerie localement au sein de l'infrastructure du projet Fedora. L'objectif est d'inclure cela dans Koji intégralement à terme quand ce sera suffisamment testé.

La génération de l'image Core OS repose sur le fichier de définition de conteneurs Containerfile. Jusqu'ici l'image était conçue via RPM OStree avant d'être convertie en image OCI. L'objectif est donc de sauter l'étape RPM OStree en utilisant les conteneurs, l'image de référence est basée sur une Fedora Linux avec bootc. Cela simplifie la procédure de génération de l'image et permet facilement à quiconque de reproduire ces étapes s'il le souhaite en utilisant podman.

Arrêt de publication des mises à jour de Core OS sur le dépôt OSTree. Cela fait suite au changement introduit dans la version précédente de Fedora où l'utilisation des images OCI avait débuté et que les nœuds existants allaient progressivement migrer vers ce format. Désormais maintenir la publication de mises à jour OSTree n'a plus de sens et permet de réallouer les ressources humaines et matérielles.

Le système d'intégration continue de Fedora ne prend plus en charge le format Standard Test Interface. Il évoluait conjointement avec Test Management Tool qui a maintenant les mêmes capacités et continue d'évoluer. N'avoir plus qu'un format permet de simplifier la maintenance et l'outillage. Il y avait de plus en plus d'erreurs liées à l'usage de STI pour certains paquets incitant à faire la migration. Le format TMT a quelques avantages dont une meilleure organisation des tests et des environnements de tests. Les tests sont également reproductibles localement ce qui est important pour la résolution de problèmes. Grâce à l'intégration avec Packit il peut facilement exécuter les tests à partir des sources du logiciel si besoin ce qui est utile en cas de nouvelle version d'un paquet ou voir si un correctif spécifique à Fedora introduit des régressions.

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. Cette étape est faite lors de la création du projet sur le service src.fedoraproject.org, un correctif fournit automatiquement cette configuration initiale. Cela peut être manuellement désactivé lors de la création si un mainteneur ne le souhaite pas. L'intérêt est de simplifier l'accueil de nouveaux empaqueteurs mais aussi d'automatiser certaines tâches par défaut. En cas de nouvelle version d'un composant, le paquet avec cette version sera automatiquement crée pour identifier les éventuels problèmes, et s'il n'y en a pas, permettre de créer automatiquement la nouvelle version du paquet et de la diffuser si l'empaqueteur accepte cette nouvelle version. Cela peut aider à gérer plus de paquets et à mieux les maintenir sur le long terme.

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. Cela est rendu possible par la mise à jour du composant debugedit qui permet une telle opération sans trop de problèmes. En effet il peut maintenant collecter les fichiers sources d'une bibliothèque statique et réécrire les chemins vers le répertoire /usr/src/debug comme attendu par les différents outils de débogage. Cependant les informations de débogage sont fournies dans les paquets RPM des binaires pour éviter la complexité de les inclure manuellement pour les développeurs qui en ont besoin dans leur logiciel. L'espace disque nécessaire pour ces informations est considéré comme relativement négligeable pour prendre cette décision. Pour les développeurs qui ne veulent pas des informations de débogage dans leur binaire peuvent exécuter la commande strip -g après l'édition de liens.

Les macros dédiées pour générer les paquets Python reposant sur setup.py sont dorénavant dépréciées. Cela concerne les macros %py3_build, %py3_install, et %py3_build_wheel. En effet ces macros reposent sur ce script qui ne sera plus maintenu à partir d'octobre 2025 par le projet setuptools. L'objectif est d'inciter et de migrer progressivement ces paquets vers la nouvelle méthode reposant sur les macros %pyproject_* et exploitant le fichier de configuration pyproject.toml. Environ 35% des paquets Python de Fedora sont donc concernés par cette migration à venir qui permettra de moderniser et d'unifier les conventions tout en suivant les bonnes pratiques de l'écosystème Python.

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. En effet les binaires Go sont tous statiquement compilés donc l'objectif de maintenir des dépendances ne sert qu'à la construction des dits paquets. Cela concerne environ 1400 paquets pour générer 400 paquets avec un binaire Go. C'est beaucoup de travail de maintenance et cela limitait la possibilité d'inclure plus de paquets Go car il fallait empaqueter toutes les dépendances nécessaires au préalable. Cependant avec cette méthode il devient plus difficile de corriger les bogues ou problèmes de sécurité introduits par ces dépendances si Fedora ne les récupère pas. Et pour les cas où il est préférable d'avoir les dépendances gérées par le projet, cela sera un travail plus important pour un paquet donné car moins de dépendances seront déjà disponibles dans les dépôts. Le suivi des licences nécessite d'être adapté pour s'assurer qu'il n'y a pas de problèmes de compatibilité mais des outils existent déjà pour réduire cette problématique.

Les paquets NodeJs utiliseront un nouveau formalisme pour le chemin de leurs dépendances. En effet le répertoire %{_libdir}/node_modules pointait vers un répertoire spécifique à une version de NodeJs comme %{_libdir}/node_modules20 pour la version 20 de NodeJs. Mais cette solution était plutôt pénible avec Fedora qui propose plusieurs versions de NodeJs en parallèle. L'objectif est de mettre en commun %{_libdir}/node_modules pour les modules où c'est possible, et pour ceux qui ont par exemple un binaire WASM, ils seront affectés dans un répertoire dépendant de la version. Cela simplifie la procédure d'empaquetage de ces composants tout en réduisant les doublons et en évitant les incompatibilités. Cela aide également à mettre en évidence les dépendances binaires cachées pour les reconstruire au sein du projet Fedora, ou les supprimer si cela n'est pas possible, à terme.

Les macros CMake ne fourniront plus de variables d'installation non standards. Cela concerne les variables -DINCLUDE_INSTALL_DIR, -DLIB_INSTALL_DIR, -DSYSCONF_INSTALL_DIR, -DSHARE_INSTALL_PREFIX et -DLIB_SUFFIX. Cela ajoute de la confusion notamment parce que la signification de certaines variables n'est pas transparente comme INCLUDE_INSTALL_DIR qui pourrait attendre des chemins relatifs ou absolus. CMake 3.0 a standardisé beaucoup de choses dans GNUInstallDirs qui sont massivement utilisés depuis. Cela permet de mieux s'intégrer dans l'écosystème de ces projets et limite le risque d'erreurs lors de la construction des paquets.

L'assembleur YASM est considéré comme déprécié pour utiliser NASM à la place. Il n'est en effet plus maintenu même si encore utilisé dans quelques paquets tel que Firefox. D'autres distributions ont déjà sauté le pas.

Ajout des nouveaux 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. L'intérêt est d'avoir un moyen standard d'étendre les options de compilation d'un paquet plutôt que chacun les édite à sa sauce et cela permet dans le même temps de voir facilement quels paquets et quelles options sont personnalisés.

Certaines limitations de l'outil gpgverify utilisé par les mainteneurs de paquets sont corrigées permettant de supprimer des méthodes de contournement associés. En effet l'outil est utilisé pour s'assurer que les sources pour construire le paquet sont bien celles souhaitées. Par exemple il était incapable de lire plusieurs clés GPG fournis dans un fichier dédié comme nginx pouvait le faire. Il était également incapable de gérer automatiquement la signature des sommes de contrôle des archives, il exigeait que l'archive des sources elle même soit signée ce qui n'était pas toujours le cas. Maintenant il prendre également en compte les clés au format keybox. Le tout améliore la maintenance des paquets concernés mais évite aussi la possibilité de contourner la sécurité dans certains cas.

La communauté francophone

L'association

Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.

Nous lançons donc un appel à nous rejoindre afin de nous aider.

L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.

Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

• Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
• Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
• Concevoir des goodies ;
• Organiser des évènements type Rencontres Fedora dans votre ville.

Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.

Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuelles chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l'avons mis en place en visioconférence sur Jitsi.

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.

Le moins que l'on puisse dire, c'est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège, Sylvain Réault et les autres contributeurs et relecteurs pour leurs contributions.

La synchronisation du travail se passe sur le forum.

Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.

Comment se procurer Fedora Linux 43 ?

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

Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.

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

De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 43.

En ce mardi 16 septembre 2025, 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é. :)

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 des 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 Kévin Raymond (pseudo shaiton), ancien contributeur de Fedora et de Fedora-fr.org.

Sommaire

• Conclusion

Bonjour Kévin, peux-tu présenter brièvement ton parcours ?

Perso ? Au sein de la communauté ? C’est un peu trop large pour être bref… Curieux et créatif, j’ai découvert l’informatique, l’électronique et la programmation au Lycée. J’ai eu la chance que mon père fasse le choix de Linux pour moi et s’occupe de mes premières installations… Voire configuration matérielle. Au début il fallait Internet pour configurer Internet (recompilation de pilotes de périphériques) c’était un beau casse-tête sans personne pour vous aiguiller. Bon OK si on remet dans l’ordre au tout début il n’y avait pas la problématique du Wi-Fi. J’ai poursuivi mes études par un DUT GEII (Génie Électrique et Informatique Industrielle) en poursuivant sur une licence puis une école d’ingénieur électronique/informatique en alternance. Plus les années passaient, plus j’avais de projets informatiques ou électroniques perso ou professionnels à réaliser et plus je m’éloignais du monde Windows, plus je me sentais chez moi sous Linux.

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

Initialement traducteur francophone, j’en suis arrivé à être le coordinateur principal de l’équipe francophone. J’ai également contribué à l’internationalisation des sites internet du projet Fedora. Ce qui m’a amené à en être un des mainteneurs principaux pendant quelque temps et de m’occuper du déploiement des nouvelles versions à chaque nouvelle sortie de version de Fedora. De là j’ai intégré l’équipe infrastructure afin de pouvoir suivre ou déclencher les mises à jour des sites. Étant un des traducteurs principaux, j’ai rejoint l’équipe documentation pour la même raison que l’équipe site internet : améliorer le déploiement des traductions. Et c’est également pour les traductions que je suis devenu coordinateur Transifex, une des plateformes de traduction utilisée un temps par le projet. Il a fallu accompagner les développeurs pour la migration et assurer le suivi du déploiement. Le problème principal étant qu’un développeur ne se rend pas compte qu’une traduction est disponible ou même qu’elle n’est pas inclue dans sa dernière version. Ayant un pied dans pas mal de portes, j’en suis venu à aider la coordination de chaque sortie de versions de Fedora. Ça c’est pour la partie productivité, mais il y a la partie sociabilité qui est une part importante de la vie d’un contributeur. Je suis devenu ambassadeur du projet Fedora jusqu’à en devenir un mentor. J’ai également intégré le bureau de l’association Fedora-Fr, devenue Borsalinux-Fr lors de mon mandat. J’ai dirigé quelque temps la production de goodies pour l’équipe FR, les réunions hebdomadaires et co-organisé une rencontre internationale à Paris − le FUDCON − après en avoir été plusieurs fois un participant actif (aux États-Unis, Italie, Suisse).

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

Pour le produit, c’était « Fedora Core » à l’époque : pour la nouveauté. Les distributions GNU/Linux étaient en plein développement, beaucoup de nouveautés arrivaient chez l’un avant l’autre. J’en ai essayé plusieurs et j’ai beaucoup aimé les choix proposés sous Fedora Core, j’y suis resté depuis 2005 (au moins en perso, si l’entreprise ne me laissait pas le choix).

Pourquoi contribuer à Fedora en particulier ?

Quant au projet et bien c’est parce que le produit me plaisait que tout naturellement c’est là que j’ai participé. Autant contribuer à ce dont on se sert tous les jours. Bon je dois quand même dire que c’est le programme d’ambassadeur qui m’a permis d’être inclus. Les forums d’entraide je voyais plutôt ça comme un mal nécessaire. En arrivant sur Paris, j’ai eu la chance de pouvoir rencontrer physiquement des passionnés prêts à vous écouter et vous aiguiller sur vos aspirations. Merci à Mathieu Bridon (dit « bochecha ») sans qui je serai resté de l’autre côté de la fenêtre.

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

Très et trop peu. Je maintiens la traduction du logiciel GNU Make. D’ailleurs il me faut la rafraichir depuis la dernière mise à jour. J’en suis devenu le mainteneur parce que le précédent ne répondait plus et que la traduction actuelle ne me convenait pas. Si quelqu’un veut le reprendre je m’en sépare bien volontiers ! Ensuite j’ai des contributions ponctuelles sur mes interactions professionnelles. Principalement pour du correctif je n’ai pas une part active malgré mon envie. J’essaye autant que possible de tester les nouvelles versions de Fedora dès la version Alpha. Grâce à ma connaissance de Fedora, j’ai intégré le projet OLPC France où j’ai pu apporter mon expertise « Fedora » pour les outils de sauvegarde et mise à jour des XO (nom des ordinateurs portable du projet OLPC basés sur la distribution GNU/Linux Fedora). Et je suis même allé à Madagascar gérer le déploiement d’une mise à jour distribution de l’ensemble d’un parc. Expérience très enrichissante.

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Oui autant que possible. C’est mon univers, je maîtrise l’environnement et je n’ai pas besoin de chercher comment faire telle ou telle actions ce qui est bien plus rapide. J’apprécie aussi énormément les choix proposés par défaut. GNOME et son mode non intrusif me permet de rester concentré sur le principal (en espérant que la proposition du choix par défaut KDE ne sera pas acceptée…) Mais c’est aussi parce que Fedora fait partie de moi, je me suis construit avec le produit, avec le projet et avec la communauté. C’est comme quitter son pays natal, on peut le faire, mais on n’est plus chez nous. Je me sens très bien sous Fedora et si je veux aider, corriger ou contribuer, je sais déjà comment m’y remettre.

Est-ce que tes contributions à Fedora sont un atout direct ou indirect dans ta vie professionnelle ? Si oui, de quelle façon ?

C’est un atout direct bien évidemment. Étant ingénieur en systèmes embarqués Linux, autant maîtriser l’environnement qui permet de répondre au besoin de l’entreprise. Dans l’entreprise on doit répondre à un besoin. Et pour ça l’humain invente des outils. S’il ne maîtrise pas ses outils il est moins productif et perd une part de ses capacités pour s’adapter à son environnement. D’un autre côté, j’aime le produit Fedora (peut-être maintenant surtout pour la Communauté) et travailler sous Fedora c’est vouloir se lever le matin et être accueilli par quelque chose qui nous fait plaisir. C’est devenu important pour mon bien être.

Tu as été actif sur de nombreux projets de Fedora durant quelques années tout en étant non employé de Red Hat, est-ce que cela a été un frein dans ta participation d’une quelconque façon ?

Absolument pas. J’étais assez pris par toutes mes contributions pour ne pas chercher à vouloir faire de la politique. Il y avait déjà assez de Gourous dans l’équipe française pour que je ne m’y colle pas. Au travers de Red Hat j’ai trouvé du soutien, des conseils et du professionnalisme. Mais également des amis.

Qu’est-ce que tu as fait plus exactement pour l’infrastructure et les sites web du projet Fedora ?

Pour les sites web, j’ai cherché à faire en sorte que mes traductions soient utilisées, déployées. C’est bien beau de passer ses nuits à traduire plutôt que dormir ou réviser, mais si le jour J la traduction n’est pas utilisée, à quoi cela sert-il ? Et si on te répond « arf, si ça avait été publié 12h plus tôt ça aurait apparu, maintenant il faut attendre le prochain déploiement dans 6 j » ça frustre. Et parfois ce n’est pas qu’une question de date c’est aussi un problème de code. Le développeur ne sait pas qu’une traduction est disponible, il ne l’utilise donc pas. J’ai donc pris en charge la synchronisation des équipes de traduction avec la génération des différents sites. J’ai créé des outils et modifié les process de déploiement des sites afin que les traducteurs soient au courant des dates et que l’équipe sites web déploie automatiquement les traductions sans étapes manuelles inutiles. Côté infra j’étais là pour seconder l’équipe sur le déploiement des sites internet. Je pouvais déployer moi-même la version de test du site fedoraproject.org afin que les traducteurs puissent relire leurs traductions et soumettre des problèmes/correctifs avant le déploiement le jour J (pour rappel une nouvelle version tous les 6 mois). En tant que coordinateur principal de l’équipe de traduction francophone, j’étais aux premières loges pour corriger les problèmes et indiquer la procédure de test aux autres équipes.

Tu as aussi géré la traduction quelques années entre Thomas Canniot et Jean-Baptiste Holcroft, qu’est-ce qui t’a attiré dans cette activité et qu’est-ce que tu as fait ?

Ça a été entre mon année d’étude en Écosse ou j’ai beaucoup amélioré mon anglais et ma première année d’école d’ingénieur à Paris. Si j’ose l’annoncer à voix haute, j’ai eu beaucoup de temps perso lors de mes années d’école d’ingénieur c’est grâce à tout ce temps libre que j’ai pu plonger dans le projet Fedora. Et Matthieu, mon mentor m’a correctement accompagné pour trouver là où je serais le plus utile, l’équipe de traduction où Thomas s’est quasiment retrouvé tout seul. Il gérait une équipe d’1,5 personne en se comptant lui-même. Je suis arrivé et à deux on a abattu un travail énorme pour rattraper les dérives. Je traduisais puis lui me corrigeait. Je venais de loin, il a fallu attendre mes 24 ans que je découvre la grammaire française, les règles d’accord COI/COD… Bon ce n’était pas très fun alors je me suis spécialisé sur la syntaxe. À deux nous avons recruté d’autres traducteurs, ensuite il a vu qu’on était une équipe, il m’a laissé la main sur la traduction. J’ai vécu 2 transitions d’outils de gestion des traductions. J’ai donné beaucoup d’effort sur le projet Transifex. Jusqu’à ce que ce projet se tourne vers un modèle commercial et que le projet Fedora change d’outil. Là je me suis dit que je ne voulais pas recommencer, j’avais des projets de refonte de tout l’outil de déploiement des sites internet. L’équipe de traduction n’était plus mon sujet prioritaire. Je ne sais même plus comment Jean-Baptiste a pris la main, mais à un moment donné les projets ont migré sur le nouvel outil, et moi j’ai perdu tout ce que j’avais mis en place. Mes outils ou scripts permettant d’obtenir les dernières traductions, d’obtenir le pourcentage de complétion de traduction de chaque langue sur chaque projet. Je n’ai plus rouvert cette porte j’ai laissé la main et je me suis concentré uniquement sur la relecture et la formation des nouveaux : habitudes de traduction pour la cohérence de l’historique, utilisation de la bonne syntaxe. Jusqu’à ce qu’on ne me voie plus contribuer sur la liste de diffusion. En résumé, j’avais le développement des sites qui était prioritaire, j’avais de moins en moins de temps à accorder, une équipe de jeunes (pas dans l’âge mais dans la date d’arrivée dans l’équipe de traduction francophone) et un changement d’outil et de process qui m’ont tout naturellement écartés de mes responsabilités.

En 2012, le FUDCon (devenu Flock depuis) s’est tenu à Paris et tu en as été l’un des principaux organisateurs. Peux-tu expliquer le but de ces rencontres et de leur importance ? Quelles ont été les difficultés d’une telle organisation ? Quels souvenirs en retires-tu ?

Le FUDCon était un événement annuel (par région) qui était l’occasion pour les contributeurs de se rencontrer pour mieux se connaître mais aussi pour avancer plus rapidement sur des points particuliers et abolir les fuseaux horaires. C’était également l’occasion de rencontrer les « Redhatters ». C’est également lors de ces événements qu’on rapproche tous les organes de la communauté. Les rencontres physiques sont très importantes. Beaucoup d’échanges dans la communauté se passent en anglais, dont c’est la langue maternelle pour une grande partie. Il est parfois difficile de cerner le ton employé à l’écrit par un individu − oui toutes nos réunions étaient en chat/IRC −, c’est lors de rencontre de ce genre qu’on peut cerner le caractère d’un individu et comprendre quand il est sérieux, ironique ou espiègle. C’est aussi l’occasion d’échanger sur la vie, d’autres sujets qui ne sont pas ceux de tous les jours. Ou ouvre notre horizon. Lors de mon premier FUDCon à Zurich, j’étais tout jeune arrivé dans le projet. Je n’avais pas grand-chose à dire mais beaucoup à apprendre. Et plus je me rapprochais de l’équipe France, plus j’entendais que la communauté rêverait d’un événement en France, à Paris. Alors un jour, un peu poussé, on a monté une petite équipe pour cet événement. Il a fallu choisir une date, trouver un lieu, proposer des logements et réaliser toute la logistique :

• créer des goodies pour faire de petits cadeaux pour que les contributeurs puissent repartir avec un beau souvenir (t-shirt « tour Eiffel » et dessous de verre réutilisables)
• gérer les subventions des contributeurs, s’ils proposaient un sujet (talk) ils pouvaient bénéficier d’une subvention par Red Hat
• trouver un traiteur
• coordonner l’équipe d’orga…

J’ai rencontré pas mal de nouvelles difficultés. C’est la première fois que je gérais (en partie) un budget autre que le mien. Mais c’est également la première fois qu’on comptait sur moi — physiquement — à une si grande échelle. L’équipe d’organisation s’est principalement tournée autour des membres de l’association Borsalinux-Fr, mais on avait bien entendu des personnes en charge côté « Red Hat » sur qui se reposer puisque cet événement était sponsorisé tous les ans sur les différentes régions (Amérique, Asie, EMEA). N’oubliez surtout pas que dans EMEA il y a Europe, mais également Afrique. Ahhhh l’Afrique. C’est loin et dans l’espace et dans la culture. Je me souviens d’un appel le matin de l’événement. « Salut Kévin, j’ai raté mon avion, tu peux me trouver un autre vol » ? Oui, c’était un contributeur dont le billet d’avion était payé complètement sur le budget subvention de l’événement. Et ça paraissait naturel pour lui que je lui paie un nouveau billet pour l’avion qu’il avait raté parce qu’il est arrivé en retard à l’aéroport… Bon il a choisi de prendre lui-même le nouveau billet, il est venu et on a passé de bons moments ! C’était un des contributeurs les plus actifs de sa région à cette époque. Autre problématique plus ennuyante au long terme : j’ai utilisé mon adresse de courriel perso pour réserver le traiteur. Et je ne sais pas ce qu’il a fait, mais il s’est enregistré avec ma propre adresse de courriel sur une liste quelque part, et depuis 12 ans je reçois des courriels en tant que gestionnaire de cette entreprise. J’ai des candidatures spontanées pour des comptables, je reçois des promotions pour acheter des sardines en gros, je reçois des nouvelles de la mairie de Paris… Ça c’est pénible. Mais j’avais à l’époque l’alias de courriel @fedoraproject.org et j’aurai dû écrire avec mon contact « pro » plutôt que perso. On apprend beaucoup en contribuant dans les projets communautaires ! Finalement, avoir organisé cet événement m’a donné de l’expérience pour organiser le même genre d’événement au sein du projet OLPC — One Laptop Per Child.

Tu as aussi beaucoup rédigé et géré le magazine francophone Muffin, peux-tu nous expliquer en quoi ça consistait et ce que tu as fait ? Que penses-tu de ce format et du travail réalisé ?

Muffin c’était incroyable. Depuis mes années d’études où je devais rédiger des rapports et présenter du contenu d’une manière très formelle, j’ai appris à rédiger en LaTeX. Je pensais savoir, connaître et comprendre. Quand j’ai vu ce que mettait en place melmorabity (Mohamed El Morabity) pour le rendu, j’étais obligé de rester pour en apprendre plus ! J’ai surtout participé à la rédaction du numéro 3. C’est l’occasion de mettre en avant des nouveautés, d’anticiper sur les demandes qui vont venir dans les forums et de présenter du contenu de qualité à nos utilisateurs. J’étais tous les premiers samedi du mois aux PSL à la Cité des Sciences à Paris. C’était une rencontre mensuelle (peut-être a-t-elle encore lieu ?) où plusieurs contributeurs de plein de communautés différentes venaient à la rencontre de leurs utilisateurs. Ce magazine avait une cible de plus. C’était également quelque chose qu’on était fier de mettre en avant lors des différents salons que nous représentions (FOSDEM, Solution Linux…) Fedora misant sur les nouveautés, il est important qu’on utilise différents moyens pour annoncer les changements aux utilisateurs. C’était un moyen de plus.

Par ailleurs à la même période il y avait je crois un Linux Pratique Essentiel dédié à Fedora 13 sortie vers 2011-2012 qui a impliqué de nombreux rédacteurs de la communauté francophone dont toi. Peux-tu revenir sur cette expérience ? Quelle a été la plus-value de travailler avec un éditeur pour créer ce magazine payant ?

Hum, ça me dit quelque chose, mais je n’en ai plus aucun souvenir. J’ai peut-être très peu contribué dans ce magazine ? Je me souviens plutôt de ma première rencontre avec mon mentor, au 42 de je ne sais plus quelle rue à Paris. C’était pour un live sur Radio Libertaire pour ensuite aller à une rediffusion d’une conférence de RMS dans un lieu plein d’idées nouvelles… Y a pas à dire il se passe plein de chose à Paris !

Tu t’es ensuite mis en retrait de la communauté francophone après 2013, pour quelles raisons ?

Plus j’en faisais au sein de la communauté Fedora, plus j’étais en capacité d’en faire plus. Je n’arrêtais pas d’interagir avec les différentes équipes pour améliorer la productivité, réduire les freins rencontrés par différents contributeurs, améliorer la collaboration. Sauf qu’au bout d’un moment, on entend les oiseaux chanter par la fenêtre et on se dit « mince, c’est déjà le matin ? » aller il faut aller chercher une ou deux heures de sommeil avant d’attaquer le boulot. Celui pour lequel on est payé. J’ai passé des semaines à plus de 30h de contribution sur les projets libres. Avec le boulot à plein temps à côté. Je n’étais pas le seul, mais si en plus on se disperse dans trop de sujets on ne peut pas tous les suivre complètement. Et si en plus on est à Madagascar avec une connexion internet limité, que ça coïncide avec le déploiement d’une nouvelle version et que c’est habituellement toi qui appuies sur le bouton ? Et bien tu trouves un « jeune » tout fou que tu formes et qui passe autant de temps avec toi sur internet qu’avec sa famille, tu lui confies la tâche d’appuyer sur le bouton et d’utiliser en prod tout le process de déploiement que tu viens de changer et activer après 2 mois de refonte complète. Tu te rends compte que ça se passe bien sans toi, que ça tourne, qu’il est fiable. Tu es rassuré et tu te dis « je me suis libéré d’une charge, qu’elle est ma prochaine priorité ? » Merci à Robert Mayr (robyduck) pour cette belle succession ! À ce moment j’ai également quitté Paris pour revenir dans mes montagnes (Haute-Savoie). J’ai intégré un nouveau travail dans lequel j’ai mis tout mon temps et même plus. Je n’ai plus eu l’occasion de rencontrer les collaborateurs du projet Fedora aussi souvent et j’ai décroché. Oui j’ai trop donné pour mon entreprise à l’époque pour ce qu’elle me rendait, mais ayant relâché les rennes de la traduction FR et des sites internet, je me suis redirigé vers le loisir en montagne ce qui m’a permis de passer moins de temps sur l’ordinateur. Je n’avais plus non plus de contacts réguliers avec des gurus de l’informatique : ceux qui vous tirent vers le haut. J’avais beaucoup de connaissances sur la collaboration que j’ai acquises au sein du projet à mettre en place dans mon entreprise. Finalement, j’ai continué mes « contributions libres » mais en tant que bénévole, je suis maintenant formateur en alpinisme. Je passe beaucoup de mon temps libre dans une autre association qui n’a plus de lien avec Fedora si ce n’est le bénévolat.

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 ?

Je ne suis plus au fait des axes politiques Fedora/Red Hat, je ne sais pas à quel point le rachat de Red Hat a influé sur le projet Fedora même si j’ai vu passer quelques messages sur ce contexte. Je trouve que certains aspects sont trop éparpillés. J’ai vécu (à côté sans être contributeur) le développement de la forge Pagure (hello pingou !) mais également le choix de certains projets de partir sur GitLab ou GitHub. Il y a des avantages et des inconvénients. Personnellement, j’ai découvert Gerrit et tout ce que ça permet. Je l’ai moi-même mis en place dans mon nouvel emploi en 2014. Dès cet instant je n’ai plus réussi à contribuer au projet Fedora. Les outils utilisés étaient un frein pour moi je ne pouvais plus suivre les développements aussi facilement. Donc si je devais changer quelque chose dans le projet, on passerait tout sous Gerrit. Ok je n’ai pas répondu à la vraie question qui concernait le produit… Wayland, systemd ? Non non la politique ce n’est pas pour moi, j’aime avancer et ma première et dernière modification si ce n’est la traduction c’est l’activation de la console en 256 couleurs par défaut. Ça me suffit je vis très bien avec !

À 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 ?

J’aime me dire que c’est un produit qui évolue avec sa communauté et non pas avec une entreprise. Ce que je souhaite conserver, c’est les quatre fondations : Freedom, Friends, Features, First. Les nouvelles fonctionnalités étant ce que j’apprécie beaucoup. Je suis du genre à désactiver les mises à jour auto et aimer déclencher moi-même les mises à jour afin de surveiller tout ce qui arrive.

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

Malheureusement je n’en fais plus partie, j’aimerais. Mais je n’arriverai pas à retrouver le même sentiment en restant à distance, le contact physique ou régulier avec les contributeurs me manque. Mais de la même manière que la plongée ou le parapente me manquent. On n’a qu’une vie et elle est remplie de choix.

Quelque chose à ajouter ?

Merci beaucoup à vous d’être encore actif, aux nouveaux d’avoir pris la relève et à tout le monde de continuer à contribuer pour ce produit. C’est tous les jours que je pense aux milliers de contributeurs Fedora et aux centaines de contributeurs que j’ai connus personnellement.

Merci Kévin pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur le projet Fedora et Fedora-fr.

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.

À dans 10 jours pour un entretien avec Aurélien Bompard, développeur au sein du projet Fedora et employé Red Hat affecté au projet Fedora en particulier dans l’équipe infrastructure.

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 des 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 Nicolas Berrehouc (pseudo Nicosss), contributeur de Fedora-fr et mainteneur de sa documentation. Devenu président de l’association Borsalinux-fr en avril 2025.

Sommaire

• Conclusion

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

Je me nomme donc Nicolas, je ne suis pas informaticien de métier malgré ce que certaines personnes pourraient croire et je ne travaille pas pour Red Hat non plus. Je suis plus issu d’une formation automatisme, micro-contrôleur et électronique donc malgré tout un monde technique. Mon activité professionnelle actuelle n’est d’ailleurs pas en lien avec l’informatique ni à proprement dit avec ma formation. Je suis un touche-à-tout autodidacte qui aime apprendre et partager 🙂

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

Mes contributions directes au projet Fedora se limitent uniquement aux journées de tests ainsi que tout ce qui va toucher aux validations des correctifs apportés via testing suite à des rapports de bugs, que j’aurais initiés ou non, avant que ce ne soit poussé en stable. D’ailleurs, je rapporte soit sur le bugzilla Red Hat, soit directement upstream aussi.
Il y a aussi Anitya que j’ai pas mal renseigné à sa sortie, car j’ai vraiment trouvé que c’était un super projet.
De ce fait, mon poste de travail est tout le temps en testing et en général je bascule vers la Bêta dès qu’elle est disponible. Voilà le plus gros de mes contributions au projet Fedora.

J’ai par ailleurs fait le choix de ne pas faire partie de groupes directement au sein du projet Fedora par manque de temps.

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

J’ai découvert le monde GNU/Linux avec Slackware fin des années 90 (oui l’autre siècle 😉) mais ça a été une grosse douche froide à l’époque, donc stand-by avant de goûter à Mandrake qui proposait une utilisation plus abordable. Puis j’ai découvert Fedora Core à sa sortie que j’ai commencé à utiliser en parallèle d’un Windows, car c’était encore difficile de se défaire de ses habitudes avec certains logiciels. Mais la bascule s’est faite finalement très rapidement par la suite malgré tout et depuis pas mal d’années maintenant je n’utilise plus que Fedora Linux, tant en poste de travail que serveur d’ailleurs.

J’y voyais aussi la possibilité de faire passer des utilisateurs Windows au monde GNU/Linux juste par le fait de donner une seconde vie à leurs ordinateurs car bien souvent les utilisatrices et utilisateurs ont une utilisation basique de leurs ordinateurs.

Le Projet Fedora proposait une vision qui me correspondait assez avec l’idée d’être novatrice, s’orienter vraiment vers le Logiciel Libre et surtout une gestion communautaire, donc il était possible de ne pas rester un simple consommateur dans son coin. À l’époque Ubuntu avait pignon sur rue et était LA distribution mais malgré une grosse communauté francophone enjouée à l’époque le principe de fonctionnement ne me plaisait pas vraiment.

Pourquoi contribuer à Fedora en particulier ?

En fait, tous les champs sont quasi possibles pour contribuer. Il y a énormément d’outils disponibles pour faciliter les contributions à travers son compte FAS désormais en plus. Par ailleurs il y a une bonne dynamique et des gens passionnés donc ça donne d’autant plus envie de participer.
Fedora intègre beaucoup de technologies et d’innovations que l’on retrouvera par la suite dans les autres distributions, alors pourquoi attendre 🙂 Ça reste ma philosophie personnelle donc ça colle avec Fedora.

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

N’étant pas développeur, il m’arrive tout de même de rapporter des bugs upstream sur certains logiciels que j’utilise lorsque ce n’est pas déjà fait. En général les différents projets sont assez réactifs et ça permet toujours de faire avancer les choses. Mais sinon pas de vraies contributions à un projet particulier en tant que tel.

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Absolument pas, mon entreprise propose uniquement des postes sous Windows 10 assez verrouillés ; donc souvent quelques moments de solitude avec des réflexes propres à mon utilisation quotidienne de GNOME 😂
Après, en contexte « semi-professionnel » dirons-nous, j’ai des serveurs auto-hébergés sous Fedora Linux aussi proposant des services pour un cercle restreint comme des outils Web, Cloud, XMPP, Mail. Pour ce point c’est arrivé assez rapidement aussi car cela faisait partie d’un apprentissage que je souhaitais réaliser afin d’avoir une compréhension et une indépendance sur la gestion de mes données personnelles. Un grand merci au monde du Logiciel Libre qui permet de faire ça !

Est-ce que tes contributions à Fedora sont un atout direct ou indirect dans ta vie professionnelle ? Si oui, de quelle façon ?

Je dirais que ça a plus un aspect indirect, comme pouvoir parler technique avec des personnes qui sont plus côté informatique ou informatique industrielle et donc faciliter des résolutions de problèmes.

Tu participes essentiellement à la communauté francophone : maintenance du site web, documentation, répondre au forum, suivi de l’association, pour quelles raisons tu y contribues ? Pourquoi se focaliser sur la communauté francophone dans ton cas ?

Oui, j’ai décidé assez tôt de plus me focaliser sur la communauté francophone car malgré ce que l’on peut croire il y a une énorme demande et je pense que pour que les personnes passent le cap en France il faut un support accessible en français pour les accompagner au mieux.
J’avais regardé côté projet Fedora, mais je n’avais pas vraiment trouvé quelque chose qui pouvait avoir une portée surtout pour l’utilisateur final, car je voyais du potentiel dans l’utilisation de Fedora Linux en remplacement d’un Windows pour une utilisation dite courante. Je sais que la priorité du Projet est d’avoir des contributeurs, mais il faut des utilisateurs aussi et compter sur le fait qu’un faible pourcentage passera le cap vers la contribution.
Il y a eu beaucoup de choses de faites côté documentation en français par le projet Fedora, mais je trouve que nous avons encore très largement notre place, car les pionniers de Fedora-fr avaient déjà répondu bien avant à ce manque.

Par conséquent, je suis assez actif dans l’ensemble des domaines cités afin d’essayer de relancer une dynamique, car je sais que les personnes sont en place depuis un long moment maintenant. J’espère aussi que ça permettra à d’autres de se lancer dans l’aventure au travers de l’Association. N’hésitez pas à vous faire connaitre lors des réunions du 1ᵉʳ lundi de chaque mois !

Nous avons fourni il y a quelques années un gros effort pour moderniser la documentation, peux-tu revenir sur cet épisode et la nécessité d’une telle action ?

Oui en effet, nous avons réalisé un très très très gros travail qu’il faudrait arriver à poursuivre d’ailleurs et j’en appelle à toutes les bonnes volontés à se faire connaître.
Quoi dire sur toutes ces soirées de travail 🙂 Nous avons décidé d’une organisation pour identifier les articles obsolètes (quasi tous 😂) ainsi que les priorités par rapport aux demandes. Puis nous nous sommes répartis les articles pour la mise à jour et nous effectuions les relectures croisées. Pas sûr que ce soit à jour mais voilà ce qui a servi de support de travail. Toutes les semaines nous faisions des points via un canal IRC pour aborder des questionnements et lever des doutes dans notre travail.

Aujourd’hui l’idée est de pouvoir fournir ou améliorer des articles autour des questions récurrentes sur le Forum afin de faciliter la transition vers Fedora Linux et éviter les multiples répétitions via le Forum.

Quels manques identifies-tu au niveau de la documentation ?

Le plus gros manque est le maintien à jour de tout ce qui est disponible 🙂

Aujourd’hui il y a des articles très sollicités (comme les pilotes propriétaires Nvidia ; quelle idée d’avoir un GPU de cette marque aussi) qui mériteraient d’avoir plus de suivi mais sinon aujourd’hui l’accent est vraiment porté sur le fait de pouvoir fournir une documentation pour les questions les plus récurrentes sur le Forum afin d’éviter les redites ou recherches sur celui-ci et devoir renvoyer vers des discussions similaires.
Bien évidemment toute autre contribution pour un nouvel article est bienvenue, car nous sommes vraiment dans l’idée de partager les connaissances et c’est aussi le meilleur moyen pour découvrir d’autres choses.

Quelle importance il y a d’avoir un forum en français à propos de Fedora ? Est-ce un bon médium pour résoudre les problèmes des gens en général ?

L’anglais n’est pas vraiment une maîtrise forte en France, et c’est difficile de faire quitter Windows à des personnes en leurs annonçant que le package contient aussi la surprise de devoir se mettre à l’anglais. Il existe des traducteurs en ligne désormais mais les utilisateurs Fedora Linux francophones nous montrent bien que ce forum a son importance, car il y a régulièrement des questions et il est très consulté.
Il n’y a évidemment aucun concours avec le forum officiel en anglais du projet Fedora. D’ailleurs avant de migrer toute l’infrastructure de Fedora-fr, il s’était aussi posé la question de rejoindre le forum officiel du projet via la section non anglaise mais finalement nous avons voulu continuer à offrir tout un écosystème francophone pour continuer dans nos objectifs au niveau de l’association Borsalinux-fr.

Pourquoi penses-tu que la fréquentation du site a baissé depuis 2011 qui est le pic historique d’activité ?

Pour moi les gens sont de plus en plus devenus de simples consommateurs courant après les effets de mode ou cherchant uniquement du divertissement. Ce sont bien souvent des personnes hyper connectées mais qui ne comprennent absolument rien au fonctionnement de leurs outils et applications, ce qui est vraiment dommage. Beaucoup de personnes se sont désintéressées des ordinateurs et se concentrent uniquement sur des ordiphones ou tablettes avec pour OS Android Google ou Apple, ce qui limite les besoins de se tourner vers une distribution GNU/Linux.

D’un autre côté la distribution Fedora Linux, malgré l’intégration de nouveautés, a vraiment perfectionné tout son process et son assurance qualité donnant ainsi une distribution vraiment stable et performante. Par conséquent qui dit stabilité dit aussi moins de problèmes à régler 🙂

Au niveau des Logiciels Libres il y a aussi eu beaucoup de travail de fond pour proposer une concurrence de haut-niveau face à des logiciels propriétaires. C’est vraiment un point à souligner car beaucoup de monde ne sait même pas, bien souvent, qu’il utilise du Logiciel Libre.
Tout cet écosystème qui a gagné en stabilité et performance engendre forcément moins de demandes aussi.

Il faudrait avoir de vraies statistiques sur le nombre d’utilisateurs en fait. En ce moment il y a des articles concernant l’augmentation de la part de marché des distributions GNU/Linux mais ça reste à suivre.

Tu as participé avec Guillaume à la dernière mise à jour du site alors que tu n’es pas webmestre de métier, qu’as-tu apporté dans la procédure ?

Alors en fait ça a porté plus largement que sur le site en lui-même. Guillaume était un peu seul dans le cadre de cette nécessité de migration de toute l’infrastructure qui devenait un très gros frein pour maintenir et faire évoluer tous les outils déployés. Ça a été l’occasion de pouvoir lui redonner de la motivation puis d’intégrer ce projet pour déclencher tout ce que nous connaissons aujourd’hui.

La migration a malgré tout été très précipitée, car il y avait tout à faire et en très peu de temps.

Effectivement je ne suis pas webmestre de métier et il a fallu s’approprier très rapidement WordPress afin de proposer à minima un équivalent de ce que nous avions avant avec fedora-fr.org donc ça a été un enchainement de journées très chargées. Et comme vous pouvez le constater nous ne sommes pas des designers dans l’âme non plus 😂 Donc tout aide est la bienvenue aussi ; même si le forum est plus le point de chute.

L’idée en parallèle était d’en profiter pour rédiger de la documentation partagée sur notre Nextcloud à propos de toute notre infrastructure ainsi que notre fonctionnement interne au niveau de l’association. Ce travail est d’ailleurs toujours en cours.

Quels manques identifies-tu au niveau de la communauté francophone en général ?

Je pense que c’est ce que l’on peut retrouver un peu de partout avec un manque d’appartenance. Aujourd’hui la consommation prime et l’utilisateur ne se considère que comme un consommateur alors qu’il pourrait trouver un épanouissement personnel en participant au sein d’une communauté et de fait s’engager dans une démarche d’échanges et de partages.

Tu nous as représenté de nombreuses années aux JDLL à Lyon, qu’est-ce qui te plaît ou qui ne te plaît pas dans cet événement ? Quels intérêts trouves-tu à y aller ?

En effet, j’ai commencé à me rendre aux JDLL à partir de 2005 car j’étais désormais pas loin de Lyon et que le monde du Libre avait commencé à faire son petit bout de chemin dans ma tête, donc j’assistais à pas mal de conférences et pendant les pauses je faisais le tour des stands. C’est d’ailleurs à ce moment-là que j’ai pu rencontrer des membres de la communauté Fedora-Fr (shaiton entre autres qui était un bon recruteur ;-) ) qui tenaient le stand sur le site universitaire de la Doua à l’époque.
Puis au fil des années, j’ai passé de plus en plus de temps vers le stand Fedora/Borsalinux-Fr pour finalement me faire embringuer dans l’aventure de la tenue du stand (petit clin d’œil à number80 qui y est pour beaucoup). Depuis quelques années maintenant j’ai hérité des relations avec l’organisation des JDLL pour la tenue du stand pour Fedora/Borsalinux-Fr lors de cet évènement.

C’est un moment de l’année où il est possible de rencontrer tout type de population et je trouve ça super intéressant de pouvoir échanger avec autant de monde. Ça permet aussi de pouvoir se remettre en question, car ce n’est pas comme se réunir au sein d’une communauté où tout le monde est d’accord avec les mêmes idées. Bref c’est très enrichissant humainement !

Quelles sont tes tâches au niveau de l’association ? Qu’est-ce qui doit être amélioré à ton avis ? Et qu’est-ce qui fonctionne bien ?

Nous sommes un effectif très réduit au niveau de l’association, donc je suis multitâche 🙂 mais j’avoue que le temps me manque.
Si l’on en revient à mes débuts dans l’association j’ai surtout essayé de relancer du dynamisme et de l’animation au sein des réunions hebdomadaires tenues historiquement sur IRC. Je pense que cela est aussi dû aux années écoulées sans renouvellement des membres du bureau et un manque de bénévoles pour assurer une répartition des tâches.
Ensuite il a été décidé de passer ces réunions au pas mensuel et en visio pour essayer de toucher plus de monde. Il y a quelques passages mais ce n’est pas encore ça derrière. Dans le même temps, nous avons assuré la transparence des informations échangées lors de ces réunions en postant le compte rendu sur le forum qui est l’outil le plus fréquenté par la communauté Fedora-fr.

Une instance Nextcloud a été déployée sur notre infrastructure, ça a été l’occasion de pouvoir construire de la documentation sur les outils que nous utilisons, des procédures liées à la maintenance ou à la gestion de l’association, etc afin que tout le monde puisse s’y retrouver, voire se projeter un peu plus dans une activité de l’association. L’idée est de pouvoir assurer la continuité de fonctionnement de l’association et ce même après un départ de quelqu’un.

Nous avons la chance d’avoir encore parmi nous des piliers de l’association qui sont encore investis.
Pour le moment il y a encore pas mal de travail mais après ça devrait se calmer pour pouvoir se focaliser sur des choses j’espère plus concrètes.

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 ?

Côté distribution je n’ai pas vraiment à me plaindre, il y a certes un gros rythme qui peine à tenir les dates de sorties mais le travail est énorme et surtout la qualité du processus est arrivée à un sacré niveau de maturité. Finir l’époque où il fallait allumer des cierges et invoquer les grands esprits avant de se lancer dans une migration 😂
L’installation peut encore amener certaines questions pour des néophytes mais ensuite tout est tellement fiabilisé que n’importe qui peut s’en servir sans problème.

À 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 ?

Le côté vivant et passionné de toutes celles et de tous ceux qui participent à ce projet dans le monde. C’est vraiment quelque chose que l’on retrouve à chaque fois dans les interviews lors des élections Fedora et ça fait plaisir.

Au niveau de la distribution, qu’elle aille toujours de l’avant et propose toujours autant l’implémentation de nouveautés technologiques.

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

J’ai connu l’époque des communautés Fedora-fr très actives dans différentes grandes villes, puis ça s’est perdu et je pense qu’aujourd’hui ça ne reverra pas le jour. Idem pour d’autres grandes distributions qui avaient leurs communautés Fr.

Aujourd’hui je pense que la communauté Fedora-Fr (les personnes actives) est une bonne chose car ça répond vraiment à un besoin au niveau francophone, car l’anglais reste un peu la bête noire.
Ceci permet donc de faciliter la prise en main de Fedora Linux avec un forum de qualité ainsi que de la documentation orientée pour répondre aux débutantes et débutants tout en assurant une base de connaissances collaborative. Et ça ouvre la porte pour contribuer directement au projet Fedora par la suite.

Malheureusement tout ceci est en train de s’essouffler et je ne sais pas combien de temps cette grande aventure va durer si de nouvelles personnes ne viennent pas apporter un peu de souffle à l’équipe.
Pour ma part je trouve que c’est sociétal, donc il faudrait peut-être revoir le modèle complet mais dans tous les cas nous aurons besoin de bénévoles.

Quelque chose à ajouter ?

Un appel à volontaires 😉 Si vous voulez vous investir dans l’Association que ce soit pour des évènements, de la documentation, du webdesign, du marketing pour des goodies ou d’autres idées alors n’hésitez pas à nous contacter via le site de l’Association, lors d’une réunion mensuelle ou tout autre canal. Nous vous accueillerons avec plaisir !

Merci Nicolas pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur Fedora-fr et sa documentation !

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.

À dans 10 jours pour un entretien avec Kévin Raymond, ancien contributeur de Fedora et de Fedora-fr.org.

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 des 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 Jean-Baptiste Holcroft, un des mainteneurs de la traduction française de Fedora.

Sommaire

• Conclusion

Bonjour Jean-Baptiste, peux-tu présenter brièvement tes contributions au projet Fedora ?

Gêné par des traductions partielles de logiciels que je trouve super, j’ai aidé d’abords en signalant des problèmes, puis en traduisant, et ne voyant pas les traductions arriver, à fluidifier le processus de traduction.

Ayant compris le fonctionnement, grâce à la communauté, j’ai voulu aider cette communauté à être plus efficace, en migrant sur la très bonne plateforme de traduction Weblate, en permettant la traduction de la totalité de la documentation de Fedora (on parle ici de 3,5 millions de mots, de milliers de pages).

Transifex, la plateforme précédente, ne permettait pas un travail collectif efficace (entre les traducteurices et entre traducteurices-projets de développement).

Avec l’expérience, j’ai constaté que la communauté du logiciel libre propose une expérience désastreuse pour les traducteurs, le coût de traduction vs l’effort nécessaire pour traduire tout un système d’exploitation est monstrueux, j’ai maintenant voulu rendre cela perceptible et accessible à tous (ce site est moche, sa valeur est la mesure de traduction transverse).

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

Ses valeurs en tant que communauté m’ont intéressées.

Fedora accueille les contributeurs, leur permet de gagner en responsabilité, de financer des initiatives et de grandir en tant que personne. Si mon implication varie dans le temps, ce n’est qu’une question de temps disponible.

Pourquoi contribuer à Fedora en particulier ?

La ligne est claire, au plus proche des créateurs de logiciels libre, en collaboration, que du logiciel libre et très fiable.
C’est une mentalité que je trouve excellente et dans laquelle je me sens à l’aise.

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

J’ai contribué pendant quelque temps au projet YunoHost sur les thèmes de la traduction, de l’internationalisation et de l’empaquetage de logiciels.
Ce projet est mature et autonome sur ces deux sujets, ayant moins de temps, j’ai arrêté d’y contribuer.
Je continue à l’utiliser au quotidien, car je le considère aussi stable que Fedora pour gérer mon serveur personnel avec mes courriels, mes fichiers, mes contacts, etc.
Aujourd’hui, je m’intéresse plutôt à notre efficacité collective plutôt qu’un projet en particulier.

Est-ce que tes contributions à Fedora sont un atout direct ou indirect dans ta vie professionnelle ? Si oui, de quelle façon ?

Toute la culture technique gagnée en lisant l’actualité des projets, en contribuant via des rapports de bugs, des traductions, des développements m’ont aidé pour obtenir mon emploi actuel, et pour mon travail au quotidien.

Le logiciel libre et le fait d’y contribuer, même modestement est un lien réel, concret et palpable, très loin de l’informatique fantasmée qui ne fait le bonheur que du porte-monnaie et du pouvoir des puissants.

Dans le travail, qu’il soit lucratif, amical ou militant, je veux du concret qui nous aide à avancer, et c’est une valeur très forte du logiciel libre.

Tu as maintenu la traduction française de Fedora pendant des années, peux-tu nous expliquer l’importance de la traduction et même de l’internationalisation dans ce genre de projets ?

Le logiciel libre est un outil de lutte contre l’appropriation des communs par une minorité.
Si on veut qu’il soit un outil d’émancipation des masses, on veut réduire les barrières à l’utilisation, tout en respectant les singularités de ses utilisateurs et utilisatrices.
Un utilisateur de logiciel ne devrait pas avoir à apprendre une nouvelle langue pour utiliser un outil émancipateur et respectueux, d’où l’intérêt de ces activités.

Traduire un logiciel est une activité complexe, quelles sont les difficultés rencontrées lors de cette activité ?

Traduire est la partie facile, ça consomme très peu de temps, ce qui est compliqué c’est :

• savoir où traduire - trouver quel logiciel affiche la chaîne, trouver où il est hébergé, comprendre quelle version est à traduire, etc
• demander de pouvoir traduire un logiciel - tout n’est pas traduisible, notre pouvoir pour faire évoluer ça en tant que traducteurice est faible
• comprendre comment traduire - l’idéal c’est Weblate directement lié au dépôt de logiciel du dépôt, le pire c’est l’ouverture de Pull Request
• maintenir les traductions dans le temps - pour chaque projet

Tu as participé à la migration de la plateforme de traduction Zanata vers Weblate, peux-tu revenir sur cette tâche et les motivations derrière cette décision ?

Weblate est un outil de traduction performant, qui facilite la vie des créateurices de logiciels et des traducteurices. Cet outil est proche du dépôt de code source et permet beaucoup d’autonomie aux traducteurices pour s’organiser comme iels le souhaitent, tracer les modifications, être notifiés, etc.

Zanata, ben c’était un objet OK pour traduire, mais c’est tout, tout le reste était déficient.
À titre d’illustration, pour savoir si une traduction a été modifiée, je devais aller regarder sur chaque phrase l’historique des modifications.
Sur Weblate, l’historique est transparent et efficace, et permet de filtrer par langue, projet, composants et type de changements. Voici par exemple l'historique des changements de traduction en français sur tous les projets.
Quand Weblate est arrivé, j’ai activement démontré la pertinence de ce projet et poussé le sujet pour que nous soyons plus efficaces.

Tu as également participé à obtenir des statistiques de traduction au sein du projet Fedora, quel intérêt à cela et comment cela a été mis en œuvre ?

C’est un sujet génial, mais c’est légèrement compliqué, voici une simplification :
Une distribution Linux, c’est l’assemblage de milliers de logiciels, des lignes de code contenues dans les paquets.
Chaque paquet est disponible au téléchargement sur des miroirs, on y retrouve même les paquets d’il y a plusieurs années (j’arrive à exploiter les données jusqu’à Fedora 7 sortie en mai 2007).

En suivant de près le fonctionnement de Weblate, je me suis rendu compte que le créateur de Weblate a créé des petits outils pour : avoir des listes de tous les codes de langues connus, et d’auto-détection des fichiers de traduction.

La mécanique va donc :

• télécharger chaque paquet existant dans Fedora
• en extraire le code source
• lancer l’auto-détection des fichiers de traduction
• calculer pour chaque fichier le pourcentage d’avancement
• agréger les résultats par langue grâce aux codes connus
• puis générer un site web pour afficher les résultats

Avec mon ordinateur, cela m’a pris plus de dix jours de calcul en continu, et le téléchargement de 2 To de données pour réussir à avoir une vue sur plus de 15 ans de la distribution Fedora. Je n’ai malheureusement pas encore eu le temps d’en faire une rétrospective pertinente dans le cadre d’une conférence, faute de temps pour analyser les données. Pour l’instant, la seule partie visible est le site https://languages.fedoraproject.org. J’espère avancer sur ce sujet pour la rencontre annuelle 2025 du projet Fedora et le FOSDEM 2026.

La traduction est une activité spécifique pour chaque langue mais tout le monde a des problèmes communs vis-à-vis de l’outillage ou des situations complexes, y a-t-il des collaborations entre les différentes équipes de traduction dans Fedora ?

D’une façon générale, résoudre un problème pour une langue résous systématiquement un problème pour une autre langue.
Les traducteurs et traductrices se soutiennent beaucoup notamment pour ces raisons, soutenez-les vous aussi !

L’absence de centralisation dans cette activité rend la cohérence des traductions dans l’ensemble des logiciels libres très complexe. Peux-tu nous expliquer ces difficultés ? Est-ce qu’il y a une volonté francophone notamment d’essayer de résoudre le problème en collaborant d’une certaine façon sur ces problématiques ?

Un logiciel est une création, sa communauté peut être plus ou moins inclusive et pointue sur certaines traductions.
La cohérence vient avec les usages et évolue comme la langue de façon progressive et délocalisée.
On pourrait imaginer proposer des outils, mais si c’est un sujet très important, ce n’est pour l’instant pas mon combat.
Je vois ça comme un problème de privilégié, car spécifique aux langues ayant suffisamment de traduction, alors que la quasi-totalité des langues en ont très peu et sont incapables de tenir le rythme exigé par l’évolution de nos logiciels libres.

Je voudrais d’abord démontrer et faire acter à la communauté du logiciel libre qu’il y a urgence à améliorer notre efficacité avec des changements de processus et de l’outillage. Cet outillage pourrait sûrement permettre d’améliorer la cohérence.

Fedora n’est sans doute pas le projet le plus avancé sur la question de l’internationalisation malgré ses progrès au fil des ans, qu’est-ce que le projet Fedora pourrait faire à ce sujet pour améliorer la situation ?

Si on veut faciliter la vie des traducteurices, il faudrait envisager de permettre de traduire à l’échelle de Fedora, de façon distincte des traductions de chaque projet, comme le fait Ubuntu.
Le problème, c’est qu’Ubuntu utilise des outils médiocres (Launchpad) et n’a pas de moyen automatisé pour renvoyer ce travail aux créateurs de logiciels.
Fedora pourrait innover sur ce sujet, et réussir à faire les deux avec une bonne plateforme de traduction (Weblate) et beaucoup d’outillage pour partager ce travail avec les différentes communautés, les utilisateurices y gagneraient en confort, les traducteurices en efficacité et les projets en contributions.

Quelque chose à ajouter ?

Un grand merci à la communauté francophone de Fedora, à la communauté Fedora et à l’ensemble des communautés qui collaborent tous les jours pour nous permettre d’avoir des outils émancipateurs et qui nous respectent. Le travail réalisé au quotidien est exceptionnellement utile et précieux, merci, merci et merci.

Gardons à l’esprit que le logiciel n’est qu’un outil au service d’autres luttes dans lesquelles nous devons prendre notre part.

Merci Jean-Baptiste pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur la traduction de 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.

À dans 10 jours pour un entretien avec Nicolas Berrehouc, contributeur de Fedora-fr et mainteneur de sa documentation.

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 des 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 Johan Cwiklinski (pseudo trasher), ancien contributeur de Fedora-fr.org et actuel mainteneur du logiciel de gestion Galette.

Sommaire

• Conclusion

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

Je suis principalement développeur (PHP, Python, Java), et un peu administrateur système - complètement autodidacte. J'ai découvert le monde de GNU/Linux en 1998 en achetant avec deux camarades de fac une distribution Red Hat 5.2 :D

Ce n'est que quelques années plus tard, en 2002, que je reviendrai à Linux ; rapidement comme OS principal. J'ai testé durant cette période différentes distributions comme Red Hat, Fedora, Mandrake et Ubuntu - pour revenir définitivement à Fedora en 2006.

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

J'ai traduit de la documentation et des logiciels pour le projet.
J'ai rédigé de la documentation pour le projet officiel (un peu) et pour le communauté francophone (beaucoup plus).
J'ai rédigé des articles pour des magazines divers.
J'ai empaqueté et maintenu différents logiciels dans les dépôts.
J'ai participé à la mise en place et maintenance de certaines versions du site internet de la communauté francophone.
J'ai participé à plusieurs salons informatiques dans le Nord ainsi qu'à Paris et à Bruxelles (FOSDEM), avec d'autres contributeurs francophones de l'époque.
J'ai été responsable de la mise en place de la documentation "Fedora-fr" pendant plusieurs années.

J'ai mis en place avec l'aide d'autres contributeurs différents canaux pour apporter des contributeurs francophones à participer au packaging sur Fedora - via la rédaction d'une documentation assez complète, des présentations lors d'évènements sur Paris, un canal IRC dédié, …,

Et j'ai aidé à monter l'association "Fedora-fr" - pour laquelle j'ai été trésorier la première année d'existence.

Qu'est-ce qui fait que tu es venu sur Fedora et que tu y es resté (si tu t'en sers encore) ?

Alors, oui, je tourne encore sous Fedora ; que ce soit sur mon ordinateur personnel ou celui du boulot. J'ai même une Fedora sur un serveur dédié que j'administre 🙂

Je suis resté sur Fedora parce que la logique du projet orienté vers le logiciel libre me convenait bien, et ensuite parce que j'y participais.
Cette distribution me convient encore tout à fait aujourd'hui, je n'ai pas de raison d'en changer 😉

Pourquoi contribuer à Fedora en particulier ?

À l'époque de la sortie de Fedora, je m'y étais un peu intéressé. J'avais une petite expérience sur d'autres distributions similaires (RedHat) ou pas (Ubuntu) - mais à cette époque, un bref passage du côté de la communauté francophone (notamment sur les canaux IRC) ne m'avait pas réellement séduit.

Ce n'est que deux ans plus tard que j'y suis revenu. J'avais alors décidé de switcher sur Fedora Core 3 définitivement à titre personnel.
L'accueil de la communauté francophone a vraiment été exceptionnel, et je me suis rapidement mis à contribuer.

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

Je contribue à un logiciel libre - que je ne citerai pas - pour mon travail, depuis plusieurs années déjà.

Et je suis le leader et principal développeur du projet de gestion d'adhérents "Galette".

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Oui, je l'utilise depuis longtemps sur mes postes de travail - ainsi que des distributions approchantes (comme CentOS) sur différents serveurs que j'ai eu à gérer.

La raison est plutôt simple : chaque distribution a ses propres spécificités, et en tant que contributeur au projet, je connais assez bien celles de Fedora. C'est donc tout naturellement que je l'utilise.
J'ai aussi la chance de pouvoir choisir librement mon environnement de travail.

Est-ce que tes contributions à Fedora sont un atout direct ou indirect dans ta vie professionnelle ? Si oui, de quelle façon ?

Un certain atout, oui. Mes contributions ont pu à quelques reprises appuyer mes candidatures à certains postes.

J'ai également pas mal packagé pour le travail, que ce soit pour ajouter des paquets inexistants, ou pour en mettre à jour voire corriger d'autres.

Tu as fait partie des fondateurs du site Fedora-fr.org, peux-tu revenir aux débuts du site à ce moment là ? Comment la communauté francophone a émergé à partir du Projet Fedora né quelques mois plus tôt seulement ?

Alors, je n'ai pas fait partie des fondateurs, je suis arrivé juste après 🙂

La communauté francophone existait déjà, il y avait un site, un tout petit peu de documentation, le forum, les canaux IRC, … Tous les outils étaient déjà en place, de même que les demandes de personnes francophones.

Nous avons alors essayé de faire connaître davantage Fedora et sa communauté - avec un certain succès puisque nous avons toujours été sollicités.

Tu as rédigé ou participé à la rédaction de nombreux articles de la documentation en français à l'époque alors que tout était à faire. Était-ce de simples traductions au départ ? L'accès à des ressources même en anglais était facile à ce moment là ? Ou cela reposait plutôt sur l'expérience ?

J'ai pas mal contribué à la traduction de la documentation officielle dans un premier temps ; leur wiki de l'époque ne rendait pas spécialement la chose facile, et j'ai peu rédigé à cette époque.

Globalement, on pouvait trouver de la documentation plus ou moins facilement (tout est toujours un peu relatif), mais on la trouvait surtout en anglais - et pas forcément sur tous les sujets.
Il faillait aussi connaître un peu, et ne pas se noyer dans la masse des informations "inutiles" pour les nouveaux.

La traduction de la doc officielle était très chronophage, et servait finalement assez peu, des questions revenaient souvent.

C'est là qu'est arrivé le wiki de la doc francophone, agencé différemment, dont l'un des objectifs était de fournir toute une série d'articles pour les débutants, et qui ne posait pas certaines limites de la documentation officielle (l'installation de certains pilotes matériels ou de certaines bibliothèques notamment).

Quelle était la répartition des tâches entre pour la maintenance du site ?

Chacun faisait ce qu'il pouvait ? :D

J'étais principalement en charge de la maintenance du Wiki (backend et frontend), et de Galette. Il pouvait m'arriver de donner un coup du main sur d'autres aspects, mais c'était assez rare somme toute.

Tu as contribué à différents sites pour le Projet Fedora, lesquels ?

Au niveau du Projet lui même, je pense n'avoir contribué qu'à la documentation. Sur fedora-fr.org, la documentation, le site de l'association, et très peu les forums.

Quelles différences vois-tu entre les sites aujourd'hui et ceux de l'époque alors que le projet était naissant ?

Il y en a vraiment beaucoup :D

Du côté du projet anglophone, les pages d'accueil sont plus claires et "vendeuses" aujourd'hui. La documentation a globalement pas mal changé, on s'y retrouve plus facilement, et c'est mieux indexé par les moteurs de recherche.

Du côté francophone, le changement le plus notable est certainement l'abandon des forums historiques pour le passage à une solution plus moderne et lisible 🙂

Tu as également crée et tu maintiens toujours le logiciel Galette pour gérer l'association, pourquoi avoir crée ce logiciel ? En dehors de Fedora-fr il y a d'autres utilisateurs ?

Je n'ai pas créé Galette. Le projet a été créé en 2003 sous l'impulsion de l'ALDIL (LUG de Lyon).
Peu de logiciels de gestion d'association de cette époque existent encore aujourd'hui 🙂

À la création de l'association Fedora-fr en 2007, nous avons rapidement cherché un moyen de gérer les adhérents. Plusieurs projets auraient pu répondre à la demande, mais Galette était celui qui collait le plus.

J'ai donc entrepris de mettre en œuvre une instance de Galette. Je suis tombé sur deux-trois soucis qui devaient être corrigés, j'ai donc commencé à contribuer au projet.

Rapidement, le projet a eu besoin d'un nouveau mainteneur, et je me suis proposé… C'était le 18 mai 2007 ^{^}

Depuis lors, je me suis consacré à l'amélioration du projet ; de nouvelle versions majeures comportant de nouvelles fonctionnalités voient le jour régulièrement.

À ce que j'en sais, plusieurs centaines d'associations utilisent Galette aujourd'hui - difficile de savoir exactement.

Tu as globalement fait un pas de côté à partir de 2012 de Fedora-fr et même de Fedora en général, peux-tu expliquer pourquoi ?

J'ai effectivement commencé à m'éloigner du projet en 2012, je continuais à participer notamment au niveau packaging, mais j'ai tout arrêté depuis 2021.

Il n'y a pas de raison vraiment particulière, ma situation personnelle a pas mal évolué depuis toutes ces années ; je n'ai plus autant de temps libre, et aussi d'autres centres d'intérêt.

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 ?

Je n'ai trop rien à répondre sur le sujet 🙂

À 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 dirai l'aspect communautaire et libre ; c'est quand même ce qui fait que j'utilise la distribution depuis toutes ces années 😉

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

Je ne suis plus trop au faîte de tout cela, et depuis trop longtemps je pense… Je ne connais pas la situation de la communauté francophone aujourd'hui.

Quant à changer des choses… Là encore, je ne sais pas trop.

Quelque chose à ajouter ?

Merci aux contributeurs actuels de continuer le travail entrepris et de continuer de faire vire la communauté !

Merci Johan pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d'en découvrir un peu plus sur la communauté Fedora-fr.

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.

À dans dix jours pour un entretien avec Jean-Baptiste Holcroft, un des mainteneurs de la traduction française de Fedora.

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 des 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 Thomas Canniot (pseudo MrTom), ancien traducteur de Fedora en français et fondateur de l’association Fedora-fr.

Sommaire

• Conclusion

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

Mon parcours est assez banal j’estime. Quand j’étais petit, je bidouillais sur un Amstrad CPC 6128 en Basic. Quand nous avons reçu notre premier ordinateur Windows en 1997, j’étais vraiment curieux de comprendre comment cela fonctionnait. J’ai rapidement découvert les logiciels libres et adhéré à l’époque à ses grands principes. Du coup, j’ai cherché très vite à utiliser le plus possible de logiciels libres tout en sachant qu’un jour je finirais par passer à Linux.
J’ai pu tester pas mal de distributions. À la fac de Lille, je participais à l’association Campux où j’ai pu rencontrer d’autres étudiants qui étaient sur Linux.

Question études, j’ai fait des études d’anglais puis d’ingénierie pédagogique à Lille. J’ai un master 2. Rien à voir avec l’informatique et pourtant.

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

Les contributions ont été assez larges en fait. Je participais pas mal au forum et j’échangeais pas mal avec le créateur de Fedora-fr.org à l’époque pour lui demander des demandes d’améliorations, le développement du wiki, etc. Au final, il a fini par me céder le site et c’est avec des volontaires sur canal IRC que nous avons pu constituer une équipe (LLaumgui, Trashy et d’autres) autour du site pour le renforcer techniquement et lui donner un second souffle.

Qu’est-ce qui fait que tu es venu sur Fedora ?

Je cherchais une distribution à la pointe des derniers développements qui soit stable et « sérieuse ». J’aimais le fait que Fedora soit une distribution Linux assez jeune (j’ai débuté sur Fedora Core 2). La communauté et le site étaient assez jeunes, il y avait matière à faire quelque chose sans que je n’aie moi de compétences techniques poussées et encore moins en programmation.

Pourquoi contribuer à Fedora en particulier ?

J’aimais la distribution par sa communauté et le fait que le projet s’organisait en chemin. C’était hyper stimulant de participer à quelque chose qui se construit et de voir un projet de cette nature se construire, établir des processus de contribution.
En installant Fedora Core 3 ou 4, je me suis rendu compte qu’il y avait plein de phrases en anglais partout dans le système alors que celui-ci était bien configuré en français. Je me suis du coup penché sur la traduction de la distribution et nous avons pu grâce au forum fedora-fr et au canal IRC monter une équipe de 3 ou 4 personnes qui contribuaient nuits et jours à la traduction de Fedora. J’ai fait ça pendant 6 ou 7 ans je dirais, c’était vraiment un gros boulot, parfois même stressant, car nous essayions de traduire le plus possible de lignes de texte avant la prochaine sortie de la distribution.

As-tu contribué à d’autres Logiciels Libres ? Si oui, lesquels et comment ?

J’ai participé à d’autres projets de traduction. Aujourd’hui, je m’applique à traduire le logiciel de conversion vidéo Handbrake pour Mac, Linux et Windows.

Est-ce que tes contributions à Fedora sont un atout direct ou indirect dans ta vie professionnelle ? Si oui, de quelle façon ?

Participer au projet Fedora m’a appris énormément sur l’informatique et le développement des projets logiciels. C’est une plus-value énorme sur mon profil professionnel. L’informatique est partout, et même si vous n’êtes pas concerné par le développement ou l’achat de logiciels au quotidien, savoir ce qu’est un logiciel propriétaire, un logiciel libre, les différents types de licences et les problématiques de développement et de traduction qui en découlent sont des cordes supplémentaires indéniables à mon arc. J’ai aussi appris sur le tas à ménager la chèvre et le chou entre les différents profils des contributeurs du projet, tenté tant bien que mal de motiver les troupes et établir des relations saines avec l’équipe de Red Hat en charge de la communauté mondiale de Fedora.

Tu as fait partie des pionniers de la communauté francophone de Fedora et de l’association, quelles raisons t'ont poussé à t’y lancer ?

La raison la plus simple et primaire, c’est qu’il fallait une structure financière basique pour payer le serveur du site internet fedora-fr.org et le nom de domaine. Nous avons donc monté une association loi 1901 et commencé à recevoir quelques cotisations (les nôtres) pour le financement annuel du serveur.

Peux-tu nous faire un bref historique des débuts de la communauté et de l’association ?

L’association étant lancée, nous avons cherché à ce qu’elle grossisse un peu en permettant de faire la promotion de Fedora en France, en Suisse et en Belgique. Parfois même en Afrique du Nord. Nous sommes restés une petite association, avec une trentaine de membres pas toujours à jour de leur cotisation. C’était vraiment rock’n’roll parfois :) Tous les ans, nous faisions presser des live CD d’installation de la distribution que nous revendions parfois complètement à perte. C’était un peu le Graal d’avoir un objet qui symbolisait la distribution et qui portait les couleurs de la communauté Fedora francophone. C’était si je me souviens bien notre plus gros budget annuel de dépense, mais cela nous permettait d’avoir des choses à proposer sur les salons.

Tu as été pendant quelques années président de l’association Fedora-fr à l’époque. Peux-tu revenir sur les chantiers en cours à ce moment-là et des apports que tu as pu y faire ?

Les premières années ont été des années de développement et de structuration de l’activité de l’association. Nous faisions tous cela à côté de nos études ou de nos jobs, donc nous n’avons pas créé des choses incroyables. Beaucoup de monde ignore tout le bazar que peut générer la création d’une association en France, ne serait-ce que d’avoir une banque ou une assurance qui comprennent ce que vous faites et qui vous accompagnent. C’était un gros boulot de stabilisation administrative. Avec les cotisations des membres, nous avons pu développer les activités de l’association : pour en faire la promotion sur les salons informatiques locaux ou nationaux, permettre aux membres de prendre en charge tout ou partie de leurs frais de déplacements, leur fournir des goodies et des live CD, des flyers, etc. Tout cela prend du temps à penser, créer, imprimer, organiser, etc.

Tu as été traducteur pour le Projet Fedora, et même des FWN (Fedora Week News) en podcast. Peux-tu nous dire l’importance que ça a de traduire un projet de cette taille ? Le rythme des FWN n’était-il pas trop élevé ?

La traduction c’est du bénévolat ingrat, car vous êtes en bout de chaine et c’est chez les traducteurs qu’est la pression de terminer le travail le plus vite possible avant que la distribution ne soit packagées et disponible en version finale. Le Projet Fedora nous a fréquemment réduit les deadlines de contributions, donc nous sommes allés au plus urgent très souvent.
J’avais oublié que j’avais réalisé un podcast avec Trashy. C’était vraiment fait sur un coin de table, mais c’était vraiment un plaisir d’essayer de faire ça. Oui le rythme était intense, mais j’aimais bien l’audio et le format.

Comment fonctionne le monde de la traduction logicielle ? Quels outils sont à disposition pour réaliser ce travail ?

Au tout début, c’était vraiment rock’n’roll et je ne comprenais pas réellement comment je devais le faire. Faire un commit de fichier quand vous êtes complètement novice en développement, ça relève de la sorcellerie.
On récupérait donc les fichiers à traduire, on les traduisait et on les renvoyait. Il y a(vait) une liste de diffusion pour organiser l’équipe de traduction et les processus. Pour éviter que plusieurs personnes ne travaillent sur les mêmes fichiers en même temps, ou pour chercher un relecteur, avant de publier la traduction. Nous étions plutôt bien organisés avec les petits outils à disposition. Ensuite, pour traduire, rien de tel qu’un logiciel comme Lokalize et un bon dictionnaire parfois.
Plus tard dans la vie du projet, le site Transifex a été lancé. Je l’utilise encore aujourd’hui pour traduire Handbrake avec beaucoup de nostalgie.

Le volume de traduction que cela représente est plutôt élevé, quelle était ta motivation à l’effectuer durant tout ce temps ?

En toute franchise, je l’ai fait par passion au début. Vers la fin, c’est devenu une contrainte, mais j’essayais de participer, car je ne voulais pas voir la distribution mal traduite. C’est terrible quand vous installez un logiciel et qu’il n’est pas entièrement en français. Personnellement je déteste cela.

Si ce n’est pas indiscret, tu as quitté maintenant Borsalinux-fr et le Projet Fedora, quelles en sont les raisons ?

Plusieurs raisons. Je me sentais un peu usé d’avoir participé pendant de nombreuses années et la motivation s’en est allée petit à petit.
J’ai également fait mon entrée dans le monde du travail et le temps disponible s’est considérablement réduit.
Enfin, Apple est passé par là. J’étais un peu frustré de devoir ré-installer mon ordinateur tous les 6 mois alors qu’un Mac ça ne bouge pas, vous l’allumez et ça fonctionne. Point. Mes proches avaient des Mac, des machines silencieuses qui fonctionnaient sans manipulations et sans problèmes… la tentation a été trop forte.

Que conseillerais-tu, comme lecture ou travaux, à un jeune contributeur de faire pour contribuer dans tes domaines ? Quelles compétences ou qualité sont utiles pour réaliser ce travail ?

Deux choses :
Ne pas se fixer des objectifs inatteignables. Les projets de logiciels libres sont en grande partie structurés et il faut parfois y aller doucement et faire ses preuves avant de prendre des responsabilités.
Être persévérant et ne pas se décourager. Parfois la marche peut sembler haute, mais n’hésitez pas à en parler à d’autres utilisateurs et contributeurs qui pourront vous donner un coup de main ou débloquer des situations. Ce sont des projets d’équipes, personne ne doit rester seul dans son coin.

Merci Thomas pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur la traduction dans Fedora et les débuts de Fedora-fr.

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.

À dans 10 jours pour un entretien avec Robert-André Mauchin, empaqueteur du Projet Fedora en particulier concernant l’écosystème Go et Rust.

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

La diversité des profils permet de voir le fonctionnement du projet Fedora sous différents angles, au-delà de la distribution, mais aussi comment il est organisé et conçu. Certains points s’appliquent d’ailleurs à 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 la chance d’avoir suffisamment de contributeurs et de contributrices de qualité pour permettre de donner 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 Timothée Ravier, contributeur au Projet Fedora en particulier aux systèmes dits immuables et à l’environnement KDE Plasma.

Sommaire

• Conclusion

Bonjour Timothée, peux-tu présenter brièvement ton parcours ?

J’ai commencé à m’intéresser aux logiciels open source autour de 2004 lorsque j’ai découvert Firefox (version 1.0 à l’époque) par l’intermédiaire d’un ami qui l’a téléchargé pour moi sur un CD ré-inscriptible, car je n’avais pas encore l’ADSL à l’époque. J’ai ensuite découvert Linux avec Ubuntu 6.06. Après mes études d’ingénieur en sécurité informatique, j’ai travaillé à l’ANSSI pendant cinq ans sur le projet CLIP OS et je travaille désormais pour Red Hat où je co-dirige l’équipe CoreOS, qui est responsable de la maintenance de Fedora CoreOS et de Red Hat Enterprise Linux CoreOS pour OpenShift.

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

Mes contributions à Fedora sont liées à mon intérêt pour les systèmes orientés conteneurs, parfois dénommés immuables (immutable). Je fais ainsi partie de l’équipe qui maintient Fedora CoreOS, je suis un mainteneur des Fedora Atomic Desktops (principalement Silverblue et Kinoite) et je suis membre du KDE Special Interest Group (SIG).

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

Je suis passé par plusieurs distributions Linux (Ubuntu, Gentoo, Arch Linux) mais je suis désormais sur Fedora.

Je pense que les « Four Foundations » de Fedora représentent bien mon parcours :

• Freedom : Je suis là parce que je suis intéressé par les logiciels libres, car ils permettent un partage, une mise en commun au bénéfice de tous.
• Features, First : C’est la force de la communauté Fedora d’un point de vue technologique. Je développe ce point dans les questions suivantes.
• Friends : Je me suis fait des amis dans la communauté Fedora et cela contribue à la bonne ambiance et la motivation pour continuer à contribuer.

Pourquoi contribuer à Fedora en particulier ?

Je préfère être proche des projets upstream et des dernières évolutions. C’est pour cela que j’étais pendant un long moment sous Arch Linux.

Mais le processus pour pousser des changements dans Arch Linux était plutôt flou. Il est important de noter que cela a peut-être changé désormais. Mon expérience date de plus de 6 ans et je crois qu’ils ont un processus de RFC maintenant. Le fonctionnement d’Arch Linux impose aussi des mises à jour régulières et une certaine discipline lors des mises à jour liée au modèle de développement sans version fixe.

Je commençais alors à m’intéresser de plus en plus aux systèmes à base d’images (CoreOS Container Linux et Fedora Atomic Host à l’époque) et je suis donc allé voir Fedora Atomic Workstation (ancien nom de Silverblue) pour créer une version à base de l’environnement KDE Plasma, qui est devenue Fedora Kinoite.

Le processus pour pousser des changements dans Fedora est ce qui fait la force de la distribution. Il permet d’obtenir des discussions et des décisions sur les évolutions à apporter à la distribution pour la prochaine version.

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

En dehors de Fedora, je contribue principalement au développement des projets KDE. Je fais partie de l’équipe qui maintient les applications KDE empaquetées avec Flatpak et publiées sur Flathub.

Je contribue aussi occasionnellement à différents projets open source en fonction des besoins.

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Oui, mes ordinateurs professionnels et personnels tournent sous Fedora Kinoite et mes serveurs personnels utilisent Fedora CoreOS. Une partie des serveurs que nous utilisons pour développer et produire les versions de Fedora CoreOS sont aussi sous Fedora CoreOS. D’autres sont sous Red Hat Enterprise Linux CoreOS, car ils font partie d’un cluster OpenShift.

En gros, nous sommes aussi des utilisateurs directs des logiciels que nous développons.

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

Une grosse partie de mes contributions se font dans le cadre de mon travail, mais toute la partie liée à KDE et aux Fedora Atomic Desktops est faite sur mon temps personnel.

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

Je n’ai pas plus de droits dans Fedora parce que je travaille pour Red Hat. Je dois suivre tous les processus de Fedora comme n’importe quel contributeur. J’ai d’ailleurs commencé à contribuer à Fedora avant d’avoir été employé par Red Hat.

En revanche, il est indéniable que cela m’aide pour contribuer, car j’ai régulièrement l’occasion de discuter avec d’autres contributeurs Fedora dans le cadre de mon travail.

Tu as débuté une carrière dans la sécurité pour finalement travailler pour Red Hat en tant que mainteneur de CoreOS, Silverblue, Kinoite et contributeur à KDE, pourquoi ne pas avoir continué dans la sécurité pour cet écosystème ?

Quelque part je continue à faire de la sécurité mais sous un autre angle. La sécurité que je faisais avant ne bénéficiait qu’à un petit nombre de personnes qui avait accès aux systèmes que l’on développait. La nouvelle version open source de CLIP OS devait rendre le système plus accessible mais le projet était complexe et je crois qu’il est désormais archivé.

Je travaille désormais à améliorer la sécurité de Fedora CoreOS et des Fedora Atomic Desktops sans compromettre leur utilisabilité. L’objectif est de fournir une distribution Linux avec des mises à jour robustes qui soit utilisable par des non développeurs.

Tu participes à CoreOS pour RHEL, CentOS Stream et Fedora. Peux-tu expliquer le but de CoreOS et ses principales caractéristiques ? Quelles sont les différences entre RHEL, CentOS Stream et Fedora à ce sujet ?

L’objectif pour les systèmes CoreOS est de faire tourner au mieux des applications dans des conteneurs. Pour Fedora CoreOS, c’est un système minimal, avec des mises à jour automatiques, proposant à la fois podman et moby-engine (Docker) installés par défaut, prêt à faire tourner des conteneurs sur un seul nœud ou dans le cadre d’un cluster Kubernetes.

Pour Red Hat Enterprise Linux CoreOS (et CentOS Stream CoreOS), ce sont des systèmes qui forment le socle d’OpenShift (et d’OKD), une plateforme qui intègre plein de projets open source dont Kubernetes.

Bien qu’il n’y ait pas une correspondance exacte un pour un dans la liste des logiciels inclus, Fedora CoreOS est l’upstream de CentOS Stream CoreOS et Red Hat Enterprise Linux CoreOS, de la même façon que Fedora est l’upstream de CentOS Stream, qui l’est de Red Hat Enterprise Linux.

L’architecture atomic a gagné du terrain sur les systèmes pour le bureau avec Silverblue et Kinoite et devient relativement populaire, peux-tu expliquer quel en est l’intérêt d’une telle conception pour ce genre de systèmes ?

Le principal intérêt pour un utilisateur est la robustesse et rapidité des mises à jour. Celles-ci sont préparées en arrière plan alors que le système fonctionne normalement. Il suffit alors de redémarrer pour mettre à jour son système. Il n’y a pas d’attente supplémentaire ni à l’extinction ni au démarrage.

Si une mise à jour échoue, le système reste dans l’état actuel, et il est possible de réessayer plus tard.
Si une mise à jour introduit un problème important empêchant le démarrage du système par exemple, il est possible de redémarrer et de choisir la version précédente dans le menu de démarrage de GRUB.

Les utilisateurs sont aussi poussés à utiliser Flatpak pour installer leurs applications graphiques et toolbox (ou distrobox) pour utiliser les applications en ligne de commandes dans des conteneurs.

Quels sont les défis techniques de proposer cette conception dans ces systèmes par rapport à CoreOS par exemple ?

La principale différence est la présence d’une interface graphique. Les applications graphiques doivent être parfois adaptées pour fonctionner avec Flatpak. C’est désormais le cas de la plupart d’entre elles.

Tu y contribues en tant que membre de Fedora Atomic Desktops SIG, peux-tu expliquer son rôle dans Fedora et ton activité dedans ?

Le rôle du Fedora Atomic Desktops SIG est de regrouper l’ensemble des contributeurs Fedora des différentes variantes Atomic : Silverblue, Kinoite, Sway Atomic et Budgie Atomic. Bien que chacun de ces systèmes propose un environnement de bureau distinct, ils partagent énormément d’éléments, tant au niveau des composants de base du système que de l’infrastructure Fedora. Le SIG permet donc de regrouper les contributeurs pour pouvoir les inclure dans les prises de décisions qui impactent ces systèmes.

Je participe à la maintenance des Fedora Atomic Desktops et plus principalement de Silverblue et Kinoite. Cela peut impliquer des mises à jour de paquets, des corrections de bugs dans des projets upstream ou des rajouts de fonctionnalités pour améliorer l’expérience sur ces systèmes. Je surveille aussi que tous les Atomic Desktops continuent de recevoir des mises à jour régulièrement.

Penses-tu qu’un jour ces systèmes atomic deviendront la référence par défaut ? Si oui à quelle échéance ? Quelles sont les difficultés actuelles à résoudre ?

Je l’espère ! Il est impossible de donner une échéance et cela ne dépend pas vraiment de moi. La difficulté la plus importante est la prise en charge du matériel et les pilotes qui ne sont pas intégrés dans Fedora. C’est un problème que l’on ne peut pas résoudre dans Fedora à cause des contraintes légales et qui sont traitées par le projet Universal Blue, dont la variante Bazzite (https://bazzite.gg/), est très populaire.

Pour la problématique des pilotes, est-ce que l’initiative du noyau unifié (d’avoir une image universelle et signée comprenant le noyau, initrd, la ligne de commande) te semble être une solution à cette problématique ?

Ces deux sujets ne sont pas liés.

Le problème des pilotes externes au noyau Linux upstream est divisé en deux cas principaux :

• Les pilotes propriétaires : Ils ne seront jamais ajoutés directement à Fedora pour des raisons légales et de licence.
• Les pilotes open source mais non inclus dans le noyau Linux upstream : Fedora met à jour le noyau Linux très régulièrement et suit les nouvelles versions stables peu de temps après leur sortie officielle. Il faut donc que ces pilotes soient mis à jour pour suivre les nouvelles versions du noyau et cela demande toujours du temps lorsque ceux-ci ne font pas partie du noyau upstream.

Les images noyau unifiées (Unified Kernel Images ou UKI) incluent le noyau, l’initrd et la ligne de commande du noyau dans un seul fichier. Cela présente des avantages pour mettre en place une chaîne de boot mesurée, notamment à l’aide du TPM, et donc pour offrir de meilleures garanties de sécurité. Leur intégration est encore en cours dans les variantes CoreOS et Atomic Desktops.

Les développeurs et administrateurs systèmes ont souvent besoin d’outils qui à ce jour nécessitent souvent de recourir à rpm-ostree plutôt que Flatpak ou Fedora toolbox dans le cadre d’un système immuable. Penses-tu que ces verrous sont un réel problème et qu’ils seront éventuellement résolus dans le temps ?

L’un des objectifs de la nouvelle initiative conteneurs bootables (« Bootable Containers ») est justement de rendre plus ergonomique la modification du système de base. Le système est distribué sous forme d’une image de conteneur standard (image OCI) et il est possible de la modifier à l’aide d’un Containerfile / Dockerfile et d’outils natifs aux conteneurs. Cela permet aux utilisateurs de ré-utiliser leurs habitudes et outils pour modifier aussi leur système de façon sûre et de partager le résultat à l’aide d’un registre d’image de conteneurs.

Nous allons aussi ajouter à nouveau dnf (version 5) dans ces images de conteneurs pour mettre à disposition des utilisateurs une interface familière et toutes les options de dnf lors de la construction de ces images.

Une autre piste est d’utiliser le concept des extensions systèmes de systemd (systemd system extensions ou sysexts), qui permettent d’ajouter du contenu dynamiquement à un système sans perdre les avantages de la gestion à base d’images. Les sysexts utilisent la même technologie que pour les conteneurs (overlayfs) pour ajouter des éléments (merge) au contenu des dossiers /usr et /opt de l’image de base. Je suis en train d’investiguer cette option pour rendre son usage ergonomique pour ces systèmes : https://github.com/travier/fedora-sysexts.

Il est aussi possible de modifier temporairement le système en utilisant un système de fichier temporaire monté au-dessus des emplacements en lecture seule (overlayfs). Les fichiers de /usr peuvent alors être modifiés et de nouveaux paquets RPM installés à la demande. Les modifications disparaîtront au redémarrage.

Tu participes aussi à l’équipe de KDE SIG, peux-tu expliquer son rôle dans Fedora et ton activité dedans ?

L’objectif du KDE SIG est de proposer la meilleure expérience possible de KDE sur Fedora. Nous suivons et contribuons aussi au développement de KDE upstream.

Je participe au KDE SIG en tant que mainteneur de Kinoite et développeur KDE.

GNOME reste le bureau principal de Fedora à ce jour, cependant la qualité de l’intégration de KDE progresse depuis de nombreuses années maintenant, penses-tu que la qualité entre les deux est aujourd’hui équivalente ? Est-ce que les contributions pour KDE sont freinées de par le statut de GNOME au sein du projet ?

C’est une question très difficile, car elle est très subjective. J’utilise principalement KDE sur mes systèmes, mais j’apprécie énormément le travail de design fait sur GNOME. Pour moi c’est un choix personnel.

D’un point de vue technologique, il est possible de trouver des éléments “meilleurs” dans GNOME que dans KDE et l’inverse.

Il n’y a pas de bénéfice à opposer ces deux projets. C’est au contraire la collaboration qui améliore l’expérience utilisateur.

Je ne pense pas que les contributions à KDE soient freinées par le status de GNOME dans Fedora.

L’équipe KDE SIG a récemment proposé d’améliorer le statut de KDE au sein du projet, quitte à même remplacer GNOME pour Fedora Workstation, peux-tu expliquer cette demande ? Penses-tu qu’un jour KDE remplacera GNOME au sein de Fedora ou de RHEL par exemple ?

L’idée des membres soutenant cette proposition (qui ne vient pas uniquement de personnes faisant partie du KDE SIG) est de remettre en question la place de GNOME « par défaut » dans le projet Fedora (notamment Fedora Workstation). Poser cette question force le projet à clarifier les critères qui font qu’un environnement de bureau est considéré comme majeur et donc autorisé à être représenté par une “édition” comme Fedora Workstation. Tous les environnements de bureau non-GNOME ne sont actuellement pas bien présentés sur le site de Fedora notamment.

Il est important pour un projet communautaire de pouvoir justifier ses choix, que l’on soit d’accord ou non avec les arguments présentés. Si ces choix sont perçus comme arbitraires (« c’est comme ça que cela a toujours été », « c’est un employé de Red Hat qui l’a décidé »), alors le projet Fedora perd en crédibilité. Il faut, par exemple, pouvoir justifier que GNOME est un bon choix à présenter aux utilisateurs découvrant Fedora.

Je ne pense pas que KDE va “remplacer” GNOME dans Fedora et ce n’est pas vraiment l’idée derrière cette proposition qui a été formulée explicitement de la sorte pour forcer la discussion. L’objectif est de rendre KDE plus visible dans Fedora.

Pour ce qui est de remplacer GNOME dans RHEL, c’est peu probable et cela serait une décision de Red Hat.

Penses-tu que Fedora est une distribution de référence pour utiliser KDE aujourd’hui ? Par le passé OpenSUSE, Kubuntu ou Mageia étaient souvent recommandées pour utiliser cet environnement.

Oui ! :) Fedora propose depuis plusieurs années les dernières versions de KDE à des fréquences très proches des sorties upstream. Nous sommes actuellement l’une des premières distributions à proposer le bureau KDE Plasma dans sa version 6. Le KDE SIG suit et participe activement au développement de KDE upstream et certains développeurs KDE recommandent désormais Fedora.

Je travaille avec Fedora Kinoite à rendre le développement de KDE plus abordable, notamment pour le test des versions en cours de développement.

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 ?

Je regrouperai l’intégralité des dépôts Git, codes sources, projets, suivi des bugs, etc. sur une (ou plusieurs) instance GitLab hébergée par le projet Fedora. C’est un projet qui est désormais en cours pour migrer vers Forgejo. Finies les instances Pagure (forge de développement Git), plus de Bugzilla (suivi des bugs). Il faudrait aussi abandonner les listes de diffusion pour utiliser Discourse à la place (transition aussi en cours).

D’un point de vue personnel, la migration du projet KDE vers GitLab fut un facteur déterminant dans ma capacité à contribuer au projet KDE. Le mode de contributions à l’aide de Pull Requests / Merge Requests à travers une interface web est devenu un standard qui réduit significativement la difficulté pour un premier contributeur à participer à un projet.

Je pense que c’est la prochaine étape importante pour rendre le développement de Fedora plus accessible et donc pour attirer plus de contributeurs.

À 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 ?

Le processus pour proposer un changement (Change Process). C’est la clé de ce qui fait de Fedora une distribution à la pointe, qui évolue à chaque nouvelle version et qui pousse l’écosystème en avant.

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

Malheureusement, je n’ai pas eu beaucoup d’interactions avec la communauté Fedora-fr, donc je n’ai pas grand-chose à dire.

Quelque chose à ajouter ?

Merci pour l’entretien !

Si vous souhaitez en apprendre plus sur ces systèmes, je vous recommande les documentations officielles des projets ou les présentations que j’ai réalisées (une ou deux en français).

Merci Timothée pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur les systèmes immuables de Fedora et l’environnement KDE Plasma.

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.

À dans 10 jours pour un entretien avec Thomas Canniot, ancien traducteur de Fedora en français et fondateur de l’association Fedora-fr.

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 des 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 Emmanuel Seyman (pseudo eseyman), ancien président de Borsalinux-fr et actuel empaqueteur dans l’écosystème du langage Perl.

Sommaire

• Conclusion

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

J’ai découvert Linux pendant mes études à l’EFREI, l’École FRançaise d’Électronique et d’Informatique. Ma première distribution était une Red Hat Linux 4.2 que j’ai installé sur mon PC en 1997.

En finissant mes études, je savais que je voulais travailler avec du Logiciel Libre et j’ai commencé un travail d’administrateur système et réseaux chez un hébergeur web dont les serveurs étaient sous Red Hat Linux.

Quand Red Hat a annoncé la fin de Red Hat Linux et le lancement de Fedora, je suis passé d’une distribution à l’autre. Quelques années plus tard, j’ai eu l’occasion de devenir packager (on devait en être à la Fedora 8) et, encore aujourd’hui, je continue à maintenir des paquets.

Ces jours-ci, je fais partie d’une équipe de gestion d’identité dans une entreprise qui fait de l’assurance-crédit. Je gère la partie Unix (essentiellement des serveurs OpenLDAP sous Linux) alors que mes collègues gèrent la partie Active Directory.

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

Maintenir mes paquets reste l’essentiel de mes contributions. Je gère plusieurs centaines de paquets, quasiment tous des modules Perl ou des applications écrites en Perl.

Depuis, je fais partie du SIG Server ou j’essaie de contribuer en y apportant mon expérience dans ce domaine.

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

J’utilisais déjà Red Hat Linux à la fois au boulot et chez moi donc ça a été un enchainement logique de passer sur Fedora Core 1. Je voyais d’un très bon œil de passer sur un système plus communautaire.

Pourquoi contribuer à Fedora en particulier ?

En prenant exemple sur FreshRPMS, un dépôt logiciel pour Red Hat Linux géré par Matthias Saou, j’avais commencé à faire des paquets des logiciels que j’utilisais qui ne se trouvaient pas dans Fedora, des modules Perl pour la plupart. L’étape suivante la plus logique était de maintenir ces paquets au sein du projet Fedora et je suis donc devenu contributeur Fedora.

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

À un moment donné, je me suis retrouvé à maintenir une instance de Bugzilla et j’ai commencé à remonter des bogues puis soumettre des correctifs. Au bout d’un moment, les développeurs ont jugé mes contributions suffisamment importantes pour me nommer contributeur.

De temps en temps, je reviens sur le gestionnaire de bogues du projet pour voir.

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Au niveau professionnel, j’utilise Red Hat Entreprise Linux et il m’arrive régulièrement d’ajouter certains de mes paquets à Fedora EPEL pour pouvoir les utiliser au boulot.

Est-ce que tes contributions à Fedora sont un atout direct ou indirect dans ta vie professionnelle ? Si oui, de quelle façon ?

Professionnellement, j’utilise Red Hat Entreprise Linux et mon utilisation de Fedora me permet de mieux comprendre le fonctionnement de RHEL. Il m’est déjà arrivé de mettre des paquets que je maintiens dans mon temps libre dans EPEL pour que je puisse m’en servir au boulot.

Tu es actif au sein du SIG Perl, peux-tu expliquer le rôle de ce SIG et de ton activité dans ce groupe de travail ?

Il y a pas mal d’interdépendances entre modules Perl et c’est utile d’avoir un canal Matrix dans lequel il y a tous les packageurs concernés pour qu’on discute ensemble lorsque quelqu’un tombe sur un problème.

Ceci dit, le SIG Perl est relativement informel et c’est compliqué de parler d’une activité de groupe avec des rôles bien définis.

Qu’est-ce qui t’a poussé à travailler sur les paquets de Perl ?

Je connais relativement bien le langage, ce qui facilite le débogage et la création de correctifs.

Tu es par ailleurs membre de l’association les Mongueurs de Perl, quel est ton rôle dans cette association ? Y a-t-il un lien ou une synergie entre le SIG Perl et cette association d’une quelconque façon ?

Je suis le président de l’association depuis plusieurs années.

Il m’arrive de parler de Fedora au sein des Mongueurs. En particulier, je vante le fait que Fedora contient toujours une version de Perl qui est très à jour et qu’on peut donc utiliser toutes les nouveautés du langage.

Quand je vois que l’une des associations fait quelque chose de bien, j’incite l’autre à en faire autant. C’est pour cette raison que les Mongueurs de Perl publient maintenant un article sur chaque nouvelle version de Perl sur LinuxFR.

Tu as été aussi président de Borsalinux-fr pendant quelques années, de 2011 à 2015, peux-tu expliquer en quoi consiste ce rôle ?

J’étais déjà en relation avec les gens de Fedora-fr parce que j’étais président de Parinux, le LUG de Paris, et qu’il nous était arrivés de planifier des évènements ensemble. Après avoir passé la main, j’ai pu trouver le temps pour participer aux activités de Borsalinux-fr et j’ai adhéré à l’association.

Je suis arrivé dans l’association à un moment ou les relations avec Red Hat n’étaient pas au beau fixe. Red Hat ne souhaitait pas que l’association utilise “Fedora” dans son nom, car c’est une marque déposée. En plus de ça, les personnes à la tête de l’association étaient là depuis plusieurs années et commençaient à fatiguer.

À un moment donné, l’association s’est retrouvée sans président et, lors de l’assemblée générale suivante, je me suis proposé pour le poste. Pendant mon premier mandat, j’ai surtout fait de l’administratif (changement de nom de l’association, changement de siège social, partenariat avec Red Hat…). Le suivant m’a permis d’inciter les adhérents à contribuer et d’aller présenter la distribution sur des évènements inédits pour nous.

En dehors de cela tu as également participé activement à la vie de l’association, peux-tu revenir sur quelques-unes de tes activités ?

Après avoir été président de l’association pendant 4 ans, j’ai voulu passer la main (je ne trouve pas sain qu’une même personne reste à la tête d’une organisation). Renault a accepté de prendre le poste, mais on se retrouvait alors sans secrétaire. Pour combler le manque, j’ai pris le poste et je suis resté secrétaire pendant 4 ans.

À côté de ça, je gère les goodies de l’association. De temps en temps, nous créons des goodies Fedora en plus des goodies que nous donne le Projet Fedora. Je centralise tout ça chez moi et j’envoie des goodies à chaque fois que quelqu’un représente l’association sur un évènement.

Tu as également été président de Parinux, quels liens il y avait entre cette activité et tes contributions au sein de Fedora et de Fedora-fr ?

En tant que président de Parinux, je gérais le village associatif de Solutions Linux. J’ai été contacté par quelqu’un (Thomas Canniot ?) qui voulait un stand pour l’association. De mémoire, les fondateurs de l’association comptaient utiliser le salon pour se rencontrer pour la première fois et signer les statuts de l’association. C’est comme ça que j’ai appris l’existence de l’association et du site web.

Un peu plus tard, Parinux a décidé de faire des install partys spécifique à une distribution. Pour celle de Fedora, j’ai donc contacté Fedora-Fr et une bonne partie de l’association a débarqué à la Cité des Sciences pour nous aider. De mémoire, nous avons pu faire ce genre d’évènement plusieurs fois.

Tu contribues également au dépôt externe RPMFusion, peux-tu expliquer la nature de tes contributions et ce qui t’intéresse dans ce projet ?

Contribuer à RPMFusion, c’est beaucoup dire… J’ai pu apporter mon aide de deux manières différentes. Je n’ai plus les dates en tête, donc je vais donner ça dans le désordre.

RPMFusion avait besoin d’un paquet de Bugzilla pour CentOS. J’ai donc mis Bugzilla dans EPEL et RPMFusion a pu mettre à jour sa version pour ne plus avoir a mettre à jour Bugzilla à la main.

À un autre moment (je me souviens que c’était lors d’un FOSDEM), les admins de RPMFusion cherchaient un bugmaster, quelqu’un pour gérer leur instance de Bugzilla. Étant donné que j’avais une certaine expérience, ils m’ont proposé le poste et j’ai accepté.

Qu’est-ce qui te motive à participer aux activités locales ?
Tu nous as représenté sur de nombreux salons en France, qu’est-ce qui te plaît ou qui ne te plaît pas dans ces événements ? Lesquels apprécies-tu le plus et pourquoi ? Quels intérêts trouves-tu à y aller ?

Ça permet de rencontrer des gens et de discuter avec eux, ce qui me fait toujours plaisir. Comme on retrouve toujours un peu les mêmes gens sur les villages associatifs, ça permet aussi de passer plusieurs jours en compagnie de gens qui me sont chers. Et, honnêtement, je ne sais pas ce que je ferais de mes jours de RTT si je ne les utilisais pas pour mes activités associatives.

Pour ce qui est du choix des salons, j’ai un faible pour Capitole du Libre, le salon toulousain, qui a un côté communautaire qui me plaît beaucoup.

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’aimerais beaucoup qu’on soit plus nombreux à faire la distribution, que ça soit au niveau des SIG, des tests… J’aimerais beaucoup qu’on facilite le fait de passer d’utilisateur de la distribution à contributeur.

À 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 suis très attaché à la nature libre de la distribution.

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

Je participe assez peu à la communauté francophone. Je dois avouer que j’aimerais un moyen de lire le forum qui puisse se faire depuis un terminal, mais je doute que les efforts qu’il faudrait faire puissent se justifier.

Tu participes peu à la communauté francophone, mais tu as conservé une certaine présence au sein de l’Association Borsalinux-fr comme les relations pour les goodies avec le Projet Fedora ainsi qu’avec EVL et bien sûr ta présence sur certains évènements francophones pour nous représenter. Considères-tu tout ceci comme une symbiose entre le travail du Projet Fedora et l’Association Borsalinux-fr ?

C’est surtout du Borsalinux-fr. En vérité, je gère les goodies essentiellement parce que je vais sur les salons (j’en ai donc besoin) et que les gens qui gèrent EVL sont des amis qui habitent eux aussi dans la région parisienne. Et soyons honnêtes, c’est loin d’être chronophage.

Arrives-tu à détecter ou motiver des personnes à devenir des contributeurs lors de ces évènements ?

J’essaie surtout de convaincre les gens de faire des petits pas et passer au niveau suivant. Si quelqu’un est utilisateur, je vais l’encourager à rapporter des bogues au projet. S’il le fait déjà, je vais lui proposer de tester les versions béta de la distribution… S’il participe à l’animation du stand Borsalinux-fr sur un salon, je vais lui demander s’il ne veut pas, en plus, animer un stand sur un autre salon.

Quelque chose à ajouter ?

Je trouve que ça fait déjà beaucoup… 🙂

Merci pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur le Projet Fedora et l’association Borsalinux-fr.

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.

À dans 10 jours pour un entretien avec Timothée Ravier, contributeur au Projet Fedora en particulier concernant les systèmes dits immuables et l’environnement KDE Plasma.

En ce mardi 15 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 42.

Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• La communauté francophone
  • L'association
  • La documentation
• Comment se procurer Fedora Linux 42 ?

Expérience utilisateur

L'environnement de bureau GNOME est proposé dans sa version 48. Cette version apporte comme toujours son petit lot de nouveautés.
Tout d'abord les notifications sont regroupées par application par défaut ce qui permet d'éviter de rapidement saturer la liste dans le menu idoine. Il reste possible de les déplier manuellement si on souhaite voir le détail pour une application en particulier.

Au sein de l'interface, une nouvelle police fait son apparition par défaut. Dénommée Adwaita, elle remplace l'illustre Cantarel qui remplissait ce rôle jusqu'alors. Elle est basée sur la police Inter qui permet une prise en charge plus complète des langues, une meilleure lisibilité sur les écrans à haute densité de pixels tout en étant accessible et lisible dont pour le terminal. En parlant d'affichage, la prise en charge de la technologie HDR a été introduite pour permette une meilleure qualité d'affichage avec les appareils compatibles.

De manière globale, il est possible de changer les raccourcis clavier de l'interface et le placement des nouvelles fenêtres par défaut est centré.

Comme de nombreux systèmes, GNOME propose des paramètres liés au bien-être. Il permet de rapporter le temps d'écran jour par jour au cours d'une semaine. Par ailleurs on peut lui demander de nous notifier régulièrement de faire une pause visuelle en regardant ailleurs ou en faisant quelques mouvements pendant quelques secondes. Il est également possible de définir une limite d'écran qui transforme l'interface en noir et blanc quand le temps limite est atteint. Au sein des options, pour ceux avec un matériel compatible, il est possible de configurer un pourcentage de charge maximale pour la batterie afin de la préserver dans le temps.

Au niveau applicatif, un nouveau lecteur audio très minimaliste fait son apparition : Decibels. Destiné à remplacer le lecteur vidéo Totem pour jouer un morceau individuel depuis le navigateur de fichiers. Côté visionneur d'images, ce dernier bénéficie d'améliorations pour proposer une édition légère des images affichées. La rotation, le changement de ratio ou le découpage de l'image ce qui permet de faire ces opérations simples et courantes sans utiliser un logiciel d'édition complet qui est beaucoup plus lourd. Ensuite il propose un bouton pour revenir au niveau de zoom d'origine à la demande. Enfin, les images au format RAW peuvent être affichées. Concernant le calendrier, il est possible de renseigner le fuseau horaire pour le début ou la fin d'une activité afin de simplifier l'organisation notamment de réunions internationales. Les performances de l'application sont également améliorées.

Sous le capot, un effort a été fait pour améliorer les performances de l'interface et du système. Par exemple le moteur JavaScript de GNOME consomme moins de mémoire et de processeur. En utilisant ffmpeg au lieu de gstreamer, l'indexation des gros fichiers et des métadonnées multimédia est aussi plus rapide et moins gourmand en mémoire. Les utilisateurs connectant leur écran à une carte graphique dédiée verront aussi leurs performances et la stabilité s'améliorer tandis que redimensionner ou créer de nouvelles fenêtres sera plus rapide.

L'environnement de bureau Xfce bénéficie de la version 4.20. Si cette version introduit un support expérimental du protocole d'affichage Wayland, il n'est pas encore fonctionnel et des améliorations futures devront encore être fournies à ce sujet. Mais concernant l'affichage, la prise en charge des écrans à haute résolution a été améliorée ce qui devrait réduire les flous dans l'interface ou de certaines icônes pour de tels écrans.

Dans le navigateur de fichiers Thunar, les points de montage adoptent une icône spécifique alors que les montages distants IPv6 sont désormais possibles. La barre d'outils s'enrichie avec un menu hamburger quand la barre de menu est masquée. Il permet aussi d'ouvrir facilement un nouvel onglet ou de changer la vue d'affichage du dossier en cours. Pour gagner de la place en hauteur, la décoration côté client est prise en charge ce qui permet de mettre le menu au même niveau que les touches d'actions pour réduire ou fermer la fenêtre. Des améliorations de performances sont également fournies notamment pour le transfert des fichiers ou pour afficher des dossiers avec de nombreux fichiers.

De manière globale il est possible de définir un mode d'énergie ou de performance du système dans les propriétés d'alimentation pour choisir l'équilibre souhaité entre la consommation d'énergie et les performances du systèmes. Il y a également l'apparition des profils d'affichage particulièrement utiles quand il y a plusieurs systèmes de multi-écrans à gérer pour passer d'un mode à l'autre en fonction de ses déplacements.

De nombreuses pages de paramètres ont été remaniées pour être plus simples et plus claires.

L'environnement de bureau LXQt passe à la version 2.1. C'est la première version à fournir une compatibilité complète avec le protocole d'affichage Wayland qui devrait être activé par défaut dans Fedora. En dehors de cela cette version ne fournie que des changements et correctifs assez mineurs.

Le logiciel d'installation Anaconda en profite pour également être une interface web par défaut pour Fedora Workstation. L'objectif est d'utiliser les technologies React et Cockpit pour définir cette nouvelle interface qui a été entièrement redessinée. Elle abandonne sa vieille approche de choisir les éléments à configurer dans l'ordre de son choix par l'usage d'un assistant de configuration linéaire. Donc après la configuration de la langue qui est basée par défaut sur celle de l'image en cours d'exécution, le choix de la date est ensuite suivie de l'étape de partitionnement qui a également été entièrement refaite avant de procéder à l'installation proprement dite. L'approche linéaire a été jugée plus simple d'utilisation et à maintenir même si cela ne permet pas de sauter des étapes si nécessaire, mais étant donné leur nombre réduit cela n'est pas considéré comme une grande perte.

L'aide a été remaniée dans l'application pour être affichée de côté et qui peut être plus facilement maintenue et traduite à côté du code de l'application.

Concernant le partitionnement, auparavant trois méthodes étaient disponibles :

• Entièrement automatique ;
• Personnalisé : approche dite top-down en définissant les points de montages avant de définir les détails concernant les partitions et les volumes ;
• Basé sur l'outil blivet : approche dite bottom-up où on définit les partitions et volumes avant d'y associer les points de montage.

Cela était complexe pour l'utilisateur et difficile à maintenir même si ça avait l'avantage d'être très flexible. L'objectif est maintenant d'offrir une approche plus guidée avec plusieurs choix plus clairs :

• Réinstaller entièrement sur les disques ;
• Installer uniquement dans l'espace libre disponible sur les disques ;
• Réinstaller sur un Fedora Linux existant ;
• Utiliser un partitionnement déjà existant ce qui permet à priori de configurer cela avec un autre outil au préalable ;
• Supprimer manuellement des partitions pour utiliser l'espace résiduel.

Le tout repose sur l'utilisation de la technologie Cockpit Storage ce qui simplifie la maintenance et permet d'avoir une apparence similaire avec le reste d'Anaconda. Dans le futur une installation distante par HTTPS devrait être possible grâce à cela.

Pour les autres éditions, Anaconda devient une application Wayland native. Ce changement est utile pour supprimer les dépendances liées à X11 pour les environnements de bureaux qui peuvent s'en passer ce qui réduit la taille de l'image. Par ailleurs cela permet aussi de migrer pour les installations à distance du protocole réseau VNC à RDP qui est plus performant et sécurisé. Cela a été rendu possible par l'usage progressif de systemd-localed par les différents environnements ce qui permettait une meilleure prise en charge de la configuration du clavier dans ce contexte, faute de définition suffisament commune dans le protocole Wayland encore. Autrement le changement de clavier depuis Anaconda ne se reflétait pas sur le bureau et cela pouvait mener à des soucis comme la difficulté de déverrouillage de la machine après installation car la disposition clavier n'est plus celle utilisée lors de l'installation…

L'édition KDE Plasma devient une édition à part entière, étant mise au même niveau que Fedora Workstation avec l'environnement GNOME. Cela récompense les efforts de longue haleine pour améliorer la qualité de l'intégration de KDE dans Fedora Linux. KDE était cependant déjà un environnement considéré comme assez important pour que son bon fonctionnement conditionne le report ou non d'une sortie de Fedora Linux, donc ce changement de statut n'aura pas d'impact de ce côté là. Elle sera maintenant proposée sur le site principal et mieux mise en avant.

L'écran de chargement lors du démarrage plymouth utilise simpledrm par défaut pour réduire l'attente qu'une carte graphique soit disponible. Les cartes graphiques sont des composants complexes qui peuvent nécessiter du temps pour s'initialiser. Auparavant, plymouth pouvait attendre jusqu'à 8 secondes avant de basculer dans un affichage par défaut assez disgracieux. Cependant grâce à l'UEFI qui fourni un framebuffer, il est possible d'avoir un affichage plus sympa et plus tôt par l'usage de simpledrm qui peut être exploité à cette fin. Cela n'a pas été fait plus tôt car notamment simpledrm ne fournissait pas d'information concernant la rotation de l'écran et la taille physique de l'affichage.

Cependant, dans certains cas l'affichage pourrait être plus moche par l'usage d'une résolution plus faible que ce qui est possible car l'heuristique pour définir si l'affichage est à haute définition de pixels peut se tromper. Il reste toujours possible de désactiver ce changement via la commande sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm=0"

Si vous souhaitez changer le facteur d'agrandissement, si vous avez un écran à haute définition de pixels par exemple, vous pouvez utiliser la commande sudo grubby --update-kernel=ALL --args="plymouth.force-scale=1" et changer éventuellement la valeur 1 par 2 selon votre cas.

L'environnement de bureau COSMIC bénéficie de sa propre édition Spin. Cet environnement est développé en Rust par l'entreprise System76 qui édite Pop! OS. Les progrès récents justifient selon le projet d'avoir sa propre variante, d'autant que Fedora Linux semblait être déjà une distribution recommandée pour tester cet environnement. Cependant COSMIC n'a pas le statut pour bloquer une sortie de Fedora Linux s'il s'avère trop instable.

Activation de la mise à jour automatique par défaut pour la version atomique de KDE Plasma nommée Kinoite. Ces mises à jour concernent la partie de base du système reposant sur rpm-ostree. Ces mises à jour fonctionnent en arrière plan à intervalle régulier pour être instantanément appliquées lors du prochain redémarrage.

Il est possible de désactiver la fonctionnalité en remplaçant la valeur du paramètre UseUnattendedUpdates à false dans le fichier /etc/xdg/PlasmaDiscoverUpdates.

Gestion du matériel

Amélioration de la prise en charge des webcams basées sur le protocole MIPI au lieu de USB dans les ordinateurs portables x86. Le travail entamé avec Fedora Linux 41 doit se poursuivre car ce protocole moins générique nécessite beaucoup d'adaptations spécifiques par modèle d'ordinateur portable sur le marché. Quelques nouveaux modèles doivent être pris en charge même si la route reste encore longue mais la voie est libre !

L'Intel Compute Runtime, qui prend en charge notamment le fonctionnement de l'API OpenCL pour les processeurs Intel, a été mise à jour vers la version 24.39 qui signifie également une non prise en charge des processeurs d'avant 2020 (à partir de la 12e génération). Ce changement n'a pas d'impact sur l'Intel Media Driver qui permet l'accélération matérielle pour la lecture ou l'encodage de vidéo.

Fedora restait sur l'ancienne version pour maintenir la compatibilité avec les vieux processeurs, jusqu'à l'architecture Broadwell sortie en 2015. Cependant avec l'évolution du noyau et de la couche graphique cela devenait un problème à maintenir et de l'autre côté Fedora n'était pas en mesure de fournir la compatibilité pour du matériel plus récent et les derniers correctifs qui améliorent notamment les performances.

Introduction de la pile Intel SGX pour permettre son utilisation dans le futur pour améliorer l'isolation et la protection mémoire en particulier pour les machines virtuelles. Cette protection se fait notamment en chiffrant la mémoire ce qui la rend inaccessible aux autres applications, au noyau et aux différents firmwares de la machine. Les bibliothèques et en-têtes nécessaires pour ces opérations sont fournies dans le répertoire /usr/x86_64-intel-sgx. Aucune application n'est fournie avec de telles possibilités aujourd'hui, uniquement le nécessaire pour créer des applications pouvant en tirer profit.

Intégration du projet FEX dans les dépôts pour permettre l'exécution des programmes x86 / x86_64 depuis les architectures AArch64. Contrairement à QEMU, il n'émule pas un système complet ce qui est plus performant pour émuler simplement une application non compatible avec cette architecture. Cela peut être nécessaire car de nombreuses applications non fournies par Fedora sont compilées nativement pour l'architecture x86_64 mais pas pour AArch64 alors que l'inverse est moins vrai.

Pour permettre son fonctionnement sur les Mac avec des processeurs Apple, qui ont une taille de page de 16k au lieu de 4k pour les autres machines, le composant muvm est également fourni avec pour permettre une telle compatibilité.

FEX est par ailleurs fourni par défaut dans la variante KDE Aarch64 du système.

L'installateur Anaconda utilise la norme GPT par défaut pour la table de partitionnement pour les architectures PPC64LE et s390x, l'architecture x86_64 et Aarch64 ayant déjà sauté le pas avec Fedora Linux 37. L'objectif est de réduire les différences entre les architectures sur ce point ce qui simplifie les tests et la maintenance de l'ensemble.

Les versions atomiques n'auront plus d'images compatibles avec l'architecture PPC64LE. D'après les statistiques, aucun utilisateur n'a utilisé de tels systèmes sur cette architecture. Cette suppression permet d'allouer plus de ressources matérielles et humaines pour générer et tester les images destinées pour les autres architectures où les utilisateurs sont plus nombreux de fait. Cela ne concerne pas les images de Fedora basées sur les paquets RPM qui restent disponibles pour cette architecture.

Le paquet du logiciel Zezere qui sert à automatiser l'installation et la configurations de systèmes IoT a été retiré des dépôts. L'objectif est de remplacer ce composant par systemd-firstboot car Zezere ne fonctionnait pas bien notamment sur les réseaux IPv6, ne fournissait que la possibilité d'envoyer une clé SSH personnalisée et de nombreuses fonctions promises n'ont jamais vu le jour.

Internationalisation

Mise à jour de l'entrée de saisie IBus 1.5.32. Cette version apporte principalement la prise en charge du protocole des entrées Wayland version 2 ce qui permet son utilisation dans les bureaux Sway, COSMIC et Hyprland. Il permet également d'afficher la pop-up de suggestions dans les applications XIM ou GTK2 lorsqu'elles sont utilisées dans une session Wayland.

Son aide à la saisie pour le chinois ibus-libpinyin est aussi mise à jour à la version 1.16. Il permet en outre de fournir des suggestions de ponctuations, de personnaliser la disposition du clavier ou d'afficher les convertisseurs Lua depuis un menu des méthodes d'entrées.

Proposition d'une nouvelle aide à la saisie vocale avec Ibus Speech to Text via le paquet ibus-speech-to-text qui permet de faire de la reconnaissance vocale en local. Toutes les applications compatibles avec IBus peuvent donc avoir une telle saisie vocale qui exploite le logiciel VOSK pour la reconnaissance vocale. Aucune connexion à Internet n'est requise et il gère plusieurs langues qui peuvent être facilement téléchargées si besoin. Cela permet d'améliorer l'accessibilité du système tout en préservant la vie privée.

Administration système

Les répertoires /usr/bin et /usr/sbin sont fusionnés. Ainsi /usr/sbin devient un lien symbolique vers le répertoire /usr/bin, de même que /usr/local/sbin vers /usr/local/bin. Cette séparation entre les utilitaires réservés aux superutilisateurs et les autres était artificielle et non exploitée.

À l'origine, l'objectif de /sbin était d'avoir des binaires liés statiquement qui pouvaient être utilisés dans un système en mode de secours pour dépanner en cas de gros problème au niveau du système. Mais cette méthode n'est plus appliquée depuis longtemps et cette distinction était conservée comme une relique historique. Cela devenait un poids plus qu'autre chose car avec l'avénement des droits d'utilisateurs dynamiques via polkit par exemple, le besoin d'accéder à ces outils nécessitait de donner accès à ces répertoires même pour des utilisateurs sans droits particuliers. Puis, entre les distributions, un utilitaire pouvait être rangé dans un répertoire ou un autre en fonction des choix des empaqueteurs de chaque communauté ce qui rend la portabilité des commandes entre distributions plus difficiles inutilement. D'ailleurs ArchLinux a sauté le pas il y a quelques années déjà.

Cela est la continuité de la suppression de la distinction entre /bin et /usr/bin qui avait le même genre de justifications qui a eu lieu avec Fedora 17, il y a 13 ans déjà.

DNF5 va proposer à l'utilisateur de supprimer les clés GPG qui ont expiré, ou qui ont été révoquées, plutôt que de devoir le faire à la main avec la commande rpmkeys --delete. Si la commande est interactive, le choix sera laissé à l'utilisateur de supprimer ou non la dite clé. En mode non interactif via les options -y ou --assumeno, le choix dépendra de l'option choisie pour l'appliquer automatiquement.

La commande fips-mode-setup a été retirée du paquet crypto-policies qui permet de rendre dynamiquement son système compatible avec les exigences du gouvernement américain concernant les modules cryptographiques. Cette option doit être activée lors de l'installation par d'autres moyens maintenant.

Il est ainsi possible de le faire en utilisant l'argument noyau fips=1 pour le notifier à Anaconda, si l'image a été générée avec osbuild-composer, l'option fips=true dans la section [customizations] permet d'obtenir le même effet ou si bootc est utilisé pour une image atomique de passer par cette configuration.

Le mode FIPS n'améliore pas forcément la sécurité, dans certains cas ça peut en bloquant l'usage des algorithmes obsolètes mais parfois cela peut avoir l'effet inverse en n'autorisant pas d'algorithmes plus récents jugés plus sécurisés, comme l'algorithme de chiffrement Argon2 utilisé par LUKS pour chiffrer le disque dur qui résiste mieux aux attaques effectuées par des cartes graphiques par rapport à l'algorithme PBKDF2 qui est lui autorisé. C'est un mode destiné aux entreprises ou personnes ayant besoin d'être certifiées à ce niveau.

L'objectif de ce changement est de simplifier la vie des mainteneurs qui n'ont plus à se préoccuper de cet outil et de ce que cela nécessite car de nombreux changements dans le système doivent être mis en place pour activer (ou désactiver) ce mode. Par exemple reconfigurer tous les modules cryptographiques du système tels que OpenSSH, OpenSSL, GnuTLS, NSS, libgcrypt ou le noyau lui même, fournir également un module à l'initramfs pour effectuer une vérification de l'image du noyau au démarrage de la machine et ajouter un argument pour le noyau si jamais /boot est dans une partition dédiée afin d'effectuer cette vérification.

Mais aussi le changement à la volée est source de problèmes et de confusions pour les utilisateurs. Par exemple installer Fedora Linux avec un chiffrement du disque avec un algorithme non compatible FIPS avant de l'activer après l'installation. De même si des clés de chiffrement sont générées avec OpenSSH ou autres outils avec des algorithmes non autorisés avant d'activer le dit mode. Ces situations hybrides peuvent induire des dysfonctionnement non prévus. L'objectif est de limiter ces cas problématiques en empêchant le changement à chaud.

Le navigateur de fichiers pour Cockpit cockpit-navigator est remplacé par cockpit-files. Cela suit le changement effectué par le projet qui a entamé cette réécriture et ne maintient de fait plus l'ancien module.

Les fichiers Kickstart seront distribués également comme des artéfacts OCI. L'objectif est de permettre de charger plus facilement une image de Fedora pour conteneurs qui est démarrable via le réseau. Dans ce cas précis, il était nécessaire pour l'utilisateur de récupérer et de transformer manuellement les différents fichiers depuis les dépôts RPM avec des numéros de versions très mouvants afin d'avoir les images du noyau, de l'initramfs, du chargeur de démarrage, de l'image d'installation et de lancement. Ici l'objectif est de pouvoir les fournir dans un endroit centralisé tel que ce dépôt avec des processus plus faciles à automatiser avec Ansible ou Foreman. Ces fichiers sont également signés avec GPG ce qui permet de facilement vérifier leur conformité.

Les éditions dérivées de Fedora Workstation auront par défaut le pare-feu configuré avec l'option IPv6_rpfilter=loose, ce qui suit la politique appliquée pour l'IPv4 depuis Fedora 30. En effet, avec l'option IPv6_rpfilter=strict il y avait notamment régulièrement des soucis pour vérifier la connexion à Internet pour des machines ayant plusieurs interfaces connectées au réseau tel qu'un ordinateur portable passant du Wifi au réseau Ethernet pour se connecter à son réseau domestique.

Ajout du paquet bpfman pour le déploiment et la gestion des programmes eBPF dans le système. Développé en Rust, il permet de fournir une vue d'ensemble des programmes eBPF utilisés dans le système actuellement. Il simplifie aussi leur déploiement dans un cluster Kubernetes par l'utilitaire bpfman-operator tandis que l'outil bpfman-agent exécuté au sein d'un conteneur permet de rapporter si les programmes eBPF sont dans l'état désiré.

Mise à jour de l'outil de gestion de configuration Ansible à la version 11. Cette version propose d'ajouter des tags aux variables ou valeurs pour par exemple retourner un avertissement si on essaye d'accéder une valeur marquée comme dépréciée. Les boucles de tâches peuvent avoir une instruction d'interruption. Enfin, le module mount_facts prend en charge les périphériques non locaux.

Le serveur de proxy inverse Apache Traffic Server évolue vers sa 10e version. Une nouvelle API basée sur JSON-RPC est proposée pour permettre des interactions avec des outils extérieurs. Le module traffic_ctl a une commande monitor pour rapporter en continue des métriques à jour. Les règles ip_allow.yaml et remap.config prennent en charge des intervalles d'IP nommées pour simplifier la configuration. La prise en charge du protocole HTTP/2 pour les connexions provenant du serveur d'origine a été ajoutée même si elle est désactivée par défaut. De plus, les plugins doivent être développés en C++20 uniquement au lieu du langage C.

La version de compatibilité PostgreSQL 15 a été retirée, PostgreSQL 16 reste la version par défaut. Cela fait suite à l'ajout de PostgreSQL 17 dans les dépôts comme version alternative avec postgresql17 comme nom de paquet. Le projet ne souhaite pas maintenir davantage de versions pour réduire la charge de travail tout en permettant de migrer les données d'une version à l'autre. En effet, la migration nécessite le binaire de la version actuellement utilisée pour réaliser un dump avant d'utiliser la nouvelle version pour importer ce dump. Cela signifie que les utilisateurs utilisant PostgreSQL 15 doivent préparer la migration avant la mise à niveau de leur Fedora Linux.

Les utilitaires liés au projet OpenDMARC ont été mis dans des paquets individuels au lieu du paquet opendmarc qui les fournissait tous. En effet de nombreux utilitaires notamment écrits en Perl étaient fournis avec ce paquet sans être nécessaires pour exécuter le service ce qui entrainait l'installation plus que 80 paquets Perl pour rien dans la plupart des cas. Le paquet opendmarc fournit maintenant les outils opendmarc et opendmarc-check quand le reste est fourni avec le paquet opendmarc-tools.

L'agent pam-ssh-agent a été supprimé des dépôts. Le développement a été arrêté il y a plus d'un an par le projet OpenSSH et aucun paquet actuellement maintenu n'en dépend.

Développement

La chaîne de compilation GNU bénéficie de GCC 15, binutils 2.44 et glibc 2.41. Concernant le compilateur GCC, comme d'habitude il fournit de nombreux changements. Il est possible pour l'optimisation de l'édition de lien de le faire de manière incrémentale afin que cette étape soit plus rapide en cas de petits changements dans le code source. Les très gros fichiers de code source sont également plus rapide à compiler et les erreurs les concernant sont mieux gérées. Les erreurs gagnent encore en lisibilité, en particulier pour les templates C++ ou en présentant le chemin d'exécution qui mène à l'erreur détectée.

Pour la section OpenMP, la prise en charge des normes au dessus de la version 5.0 continue sa progression avec une meilleure gestion des cartes graphiques Nvidia et AMD. Pour le langage C, la norme C23 devient la norme par défaut tandis que le début de prise en charge de la future norme C2Y a été introduit. Pour le C++, c'est la prise en charge de la future norme C++26 qui progresse et une meilleure gestion des modules introduits dans les normes précédentes.

Pour les architectures, de nombreuses améliorations pour la prise en charge des microarchitectures x86_64 dont des nouvelles instructions AMX. Côté Aarch64, ce sont les puces d'Apple qui sont prises en charge maintenant.

Concernant la bibliothèque standard C, il y a quelques changements concernant la résolution DNS. Grâce à la variable d'environnement RES_OPTIONS il est possible d'ignorer des options précisées dans le fichier /etc/resolv.conf. Ainsi utiliser RES_OPTIONS=-no-aaaa permet d'ignorer l'option options no-aaaa. Les fonctions sched_setattr et sched_getattr ont été ajoutées pour permettre de changer les options de la politique d'ordonnancement des processus du noyau, par exemple quand SCHED_DEADLINE est utilisé où certains paramètres peuvent être utilisés. La prise en charge d'Unicode 16.0 a été ajoutée, de même que de nombreuses fonctions mathématiques introduites par la norme C23. Pour l'architecture AArch64, les fonctions mathématiques vectorielles devraient être plus performantes.

Enfin pour les binutils, les extensions de l'assembleur pour les architectures AArch64, Risc-V et x86 ont été mises à jour. L'éditeur de lien peut mixer des objets avec et sans l'optimisation activée.

La chaîne de compilation LLVM progresse à la 20e version. Comme pour son concurrent GCC, les dernières normes C et C++ ont bénéficié de nombreuses améliorations pour leur prise en charge. De même, de nombreuses instructions AMX pour l'architecture x86_64 ont été ajoutées. Un nouveau vérificateur TySan fait son apparition pour vérifier les violations d'aliasing de types, donc utiliser un pointeur d'un type particulier pour accéder à des valeurs d'un autre type en mémoire ce qui dégrade les performances ou peut engendrer des bogues. Le module de télémétrie a été extrait du débogueur pour être disponible dans l'ensemble de LLVM afin de pouvoir rapporter différentes mesures et usages de ces outils aux développeurs mais cela reste désactivé par défaut.

Fedora par ailleurs fournit les outils llvm-bolt, polly, libcxx et mlir dans le paquet llvm au lieu d'être dans des paquets indépendants comme avant. Les binaires, bibliothèques et autres en-têtes sont installées dans le dossier /usr/lib64/llvm$VERSION/ au lieu de /usr, des liens symboliques sont proposés pour garder la compatibilité, l'objectif est de faciliter le passage d'une version à l'autre pour les utilisateurs.

Le cadriciel web Python nommé Django utilise la version 5.x. Les formulaires peuvent bénéficier de la notion de groupe de champs pour simplifier significativement le code du template en évitant de devoir répéter les mêmes informations pour chaque champ s'ils ont la même structure. Les modèles peuvent également recevoir une valeur par défaut obtenue par la base de données. Il est également possible de générer des colonnes qui sont calculées à partir d'autres champs de la base de données.

Mise à jour du langage Go vers la version 1.24. Côté langage, il prend en charge les alias de types génériques ce qui permet d'étendre leur champ d'applications et d'améliorer la lisibilité du code. Comme souvent avec Go, les performances sont améliorées, de l'ordre de 2-3% à l'exécution et la structure map est basée sur les tables suisses pour réduire la consommation mémoire pour les petits objets. La bibliothèque standard fournit des mécanismes pour se conformer au standard FIPS 140 concernant la cryptographie comme expliqué plus haut. Une nouvelle instruction du compilateur go:wasmexport permet d'exporter les fonctions du programme à l'hôte en WebAssembly.

Le langage Ruby brille avec la version 3.4. Le parseur par défaut passe de parse.y à Prism pour améliorer la détection des erreurs, les performances et la portabilité. La bibliothèque de socket dispose du standard Happy Eyeballs Version 2 pour améliorer la résilience et l'efficience des connexions TCP. Le compilateur juste à temps YJIT améliore ses performances pour les architectures x86_64 et Aarch64, il est également plus fiable et réduit un peu sa consommation mémoire tout en ayant la possibilité de définir une limite maximale unifiée. Parser des structures JSON doit être également 1,5 fois plus rapide, de même pour Array#each grâce à une réécriture en Ruby.

Le langage de programmation PHP s'impose de tout son poids à la version 8.4. Outre d'apporter un compilateur juste à temps basé sur IR Framework et diverses améliorations de performance, le langage propose de nouveaux concepts. Les property hooks permettent de facilement définir des structures basées sur une autre valeur pour les garder synchronisées tout en ayant une quantité de code plus réduites et avec moins de risque de faire des erreurs. Il est possible de définir une visibilité asymétrique, en autorisant la lecture d'une propriété mais pas son écriture publiquement et ce sans passer par des getters / setters. L'attribut #[\Deprecated] fait son apparition pour signaler à l'utilisateur qu'une méthode ou valeur sera probablement supprimée ultérieurement. Une nouvelle API pour manipuler les objets DOM apparaît et fournit la prise en charge de HTML5. Et d'autres changements encore.

Le langage de scripts Tcl/Tk a été mis à jour vers la 9e version. Pour des raisons de compatibilité, la version 8 reste distribuée sous le nom de paquet tcl8. Grâce à l'exploitation du 64 bits, il peut maintenant manipuler des données de plus de 2 Gio. La prise en charge d'Unicode et des différentes méthodes d'encodage a été améliorée, en ajoutant d'une part mais aussi en gérant l'ensemble des valeurs existantes. L’interaction avec le système est améliorée avec la possibilité d'envoyer des notifications, d'imprimer ou d'utiliser les icônes de la barre du système. Il y a un début de prise en charge de l'affichage vectoriel permettant d'améliorer le visuel des applications. Les capacités d’interactions tactiles sont améliorées avec la possibilité de gérer des gestes à deux doigts.

La bibliothèque de calcul scientifique en Python NumPy passe à la version majeure 2. Première version majeure depuis 2006, il fournit de nombreuses améliorations de performance en particulier autour des différents algorithmes de tri de même que la sauvegarde de gros objets. La transformée de Fourrier rapide prend en charge les types float32 et longdouble. Un nouveau type pour les chaînes de caractères de taille variable fait son apparition : StringDType qui doit fournir également de meilleures performances. La séparation entre l'API publique et privée a été aussi clarifiée avec une nouvelle structure des modules. API qui a aussi été nettoyée pour enlever ce qui n'était pas pertinent ce qui simplifie l'apprentissage de la bibliothèque.

L'outil de développement de paquets Python Setuptools a été mis à jour vers la version 74. La commande setup.py qui était non recommandée depuis plus de 5 ans disparaît, cela a nécessité notamment de changer près de 150 paquets dans le système pour en tenir compte. D'autres changements plus mineurs sont également fournis.

Mise à jour de la bibliothèque de compression zlib-ng à la version 2.2.x. Parmi les changements, sur l'architecture x86_64 les performances devraient être améliorées de 12% pour la compression avec le niveau par défaut. L'allocation mémoire est également fait en une seule fois ce qui réduit le nombre d'appels systèmes et le risque de fragmentation de la mémoire ce qui améliore également les performances globales. Le risque d'avoir un échec par manque de mémoire s'en retrouve également réduit.

Le langage Copilot avec sa boîte à outil de vérification de runtime fait son apparition. Développé en Haskell par la NASA, il permet de définir des programmes concis qui peuvent ensuite être transpilés en C99 pour permettre un haut niveau de sécurité tout en étant capable de gérer des contraintes temps réel dures ce qui est important dans de nombreux contextes embarqués. Ce langage est disponible via le paquet ghc-copilot.

La bibliothèque graphique SDL utilise la version 3 pour assurer la compatibilité avec ses versions 2 et 1.2 dorénavant. Cela passe par le paquet sdl2-compat qui fourni cette compatibilité car SDL 2 n'est plus développé.

Les anciennes versions de OpenJDK pour le langage Java à savoir 8, 11 et 17 ne sont plus fournies par les dépôts de Fedora mais devront être installées via un dépôt tiers tel que Adoptium Temurin dont le paquet adoptium-temurin-java-repository permet son activation. La maintenance des différentes versions d'OpenJDK a été longtemps une problématique pour Fedora avec leur nombre de versions avec une maintenance officielle qui augmente, cela alourdissait considérablement la charge de travail sans avoir assez de mainteneurs en face. D'autant plus que la plupart des cas d'usage se contentent bien de la dernière version LTS disponible, les versions plus anciennes répondent à des cas plus spécifiques qui peuvent se contenter d'un dépôt externe où les mainteneurs de Fedora travaillent de toute façon ce qui garantie la qualité de l'intégration. Cela diminuera la consommation de ressources pour gérer ces paquets dans Fedora mais aussi l'allégement de la charge de travail permettra de mettre à jour OpenJDK plus rapidement à l'avenir.

Le paquet de compatibilité Python pour la version 3.8 a été retiré. Cette version n'est plus maintenue par le projet Python et ce serait trop coûteux et peu sûr de poursuivre sa fourniture dans la distribution.

La bibliothèque Rust zbus version 1 a été supprimée, la version 4 ou supérieure reste proposée dans les dépôts. Une vingtaine de dépendances obsolètes étaient également maintenues pour ce composant ce qui permettra de réduire la charge de travail pour les mainteneurs et la consommation de ressources pour le projet Fedora. La compatibilité avec les dernières versions du compilateur Rust et certains bogues sur certaines architectures rendaient sa maintenance problématique par ailleurs.

La bibliothèque de compatibilité entre Rust et Python, PyO3, se voit retirer les anciennes versions 0.19, 0.20, et 0.21. Les versions 0.22 et 0.23 restent donc disponibles. Cet abandon devient nécessaire par les changements de l'API et de l'ABI de CPython qui rendent les anciennes versions de plus en plus difficiles à maintenir en état de fonctionnement.

L'utilitaire d'exécution des tests unitaires en Python python-pytest-runner est déprécié et sera supprimé dans un futur proche. Depuis 2019 il est dans un état d'abandon par le projet source, il faut depuis envisager d'utiliser pytest à la place d'autant plus que les incompatibilités avec l'outil setuptools vont en grandissant.

La bibliothèque de compatibilité entre GTK3 et Rust est marquée comme dépréciée et sera supprimée dans une prochaine version. En effet les versions récentes de gtk-rs ne le prennent plus en charge ce qui impose un coût de maintenance d'autant qu'il faut maintenir aussi les anciennes versions de compatibilité avec Cairo et GLib pour cela.

Projet Fedora

Fedora Linux proposera des archives permettant d'être installé avec Windows Subsystem for Linux. Windows a récemment amélioré la prise en charge des installations d'un tel système en dehors du magasin d'applications Microsoft ce qui rend ce changement plus intéressant. Idéalement il faut utiliser WSL 2.4.4 ou supérieur même si une procédure sera fournie pour les versions plus anciennes. Le projet Fedora ne souhaite pas à ce jour accepter les conditions pour permettre une publication directement depuis le magasin d'applications. Cela permet de faciliter l'usage de Fedora dans un tel système.

Les paquets RPM peuvent bénéficier de la fonction systemd sysusers.d pour créer des utilisateurs ou groupes dédiés lors de l'installation des paquets RPM. L'objectif à terme est de se débarasser des instructions useradd ou groupadd dans les paquets RPM voire l'usage de la macro %sysusers_create_compat. Cela va permettre d'uniformiser à terme la manière de créer de tels utilisateurs et groupes ce qui va également simplifier les scriplets des différents paquets RPM concernés. Comme cela est intégré dans le format RPM, il devient plus facile de retrouver quels utilisateurs et groupes sont créées par un paquet donné et de définir des dépendances basées sur ce critère si c'est pertinent.

Les mises à jour de Fedora CoreOS passent de OSTree à OCI. Les mises à jour proviennent ainsi du dépôt quay.io/fedora/fedora-coreos. C'est la première étape avant d'être capable de passer à bootc pour gérer la base du système qui permettrait entre autre de faire des mises à jour en miroir en copiant un système existant sur le réseau local ou de laisser l'utilisateur personnaliser facilement ses propres images.

Activation par défaut de composefs pour les images atomiques bureautiques de Fedora Linux pour les images non basées sur OSTree. Faisant suite à ce qui a été fourni pour les images CoreOS et IoT avec Fedora Linux 41, l'idée est de fournir une vérification d'intégrité des images atomiques lorsque le système tourne et d'avoir un système de fichiers du système réellement en lecture seule.

En effet, jusqu'ici l'intégrité des fichiers du système n'est vérifiée que lors de la mise à jour ou l'installation d'une nouvelle image mais rien n'empêche d'avoir une altération malveillante par exemple entre temps. Il fallait exécuter ostree fsck à la main pour vérifier manuellement si le système était conforme. De plus le système même s'il est en lecture seule en théorie, en réalité il était monté en lecture/écriture avec la commande chattr +i / ajoutée pour prévenir les modifications accidentelles.

Avec composefs, qui exploite overlayfs et EROFS, permet de supprimer ces limitations, le système de fichiers sera réellement en lecture seule et la moindre tentative de modification aboutira à une erreur au niveau du noyau Linux en toute circonstance. Les répertoires /etc et /var restent accessibles en lecture/écriture comme avant. L'objectif à terme est de fournir une vraie chaîne de démarrage sécurisée avec la vérification des signatures au niveau du système.

L'utilitaire edk2 est compilé avec des options de sécurité supplémentaires pour améliorer la sécurité des machines virtuelles reposant sur l'UEFI. Ce composant est une implémentation de l'UEFI qui est notamment utilisée par les machines virtuelles créées avec libvirt. Ce changement passe par l'activation du mode strict pour NX qui empêche l'exécution de code provenant de zone mémoire en lecture/écriture. Les pointeurs NULL sont également capturés pour éviter de déférencer le vecteur d'interruption qui existe à cette adresse ce qui peut mener à des accès mémoires non souhaités. Cela ne sera appliqué que pour les sytèmes invités avec Secure boot activé, pour éviter d'introduire des régressions pour les systèmes invités plus anciens qui seraient non compatibles avec ces options de sécurité dans un environnement où ces protections additionnelles seraient moins pertinentes.

En effet, cela est une réponse au problème de sécurité liée au composant shim pour les versions inférieures à 15.8 qui a nécessité en 2024 une mise à jour majeure des chargeurs de démarrage et du noyau Linux. Des systèmes invités avec ce problème de sécurité non corrigé entraineront une erreur mémoire prévenant toute exécution.

Les images live de Fedora Linux utilisent le système de fichiers EROFS en lieu et place de SquashFS. Ce système de fichiers est aussi en lecture seule et est plus activement développé. De fait il peut utiliser des algorithmes de compression plus moderne pour réduire la taille de l'image et a été développé pour avoir de bonnes performances sur les systèmes embarqués ce qui devrait se retrouver aussi sur des machines plus performantes.

Ajout d'un générateur de dépendances pour les extensions de GNOME Shell, permettant de lier la version de l'extension avec celle de gnome-shell à partir du fichier metadata.json de l'extension. Cela permet de détecter de manière générique et donc plus facilement et automatiquement un soucis de compatibilité entre une extension et la version de GNOME Shell fournie par le projet. Cela devrait permettre de travailler sur ces problèmes de compatibilité dès qu'ils apparaissent plutôt que d'attendre le retour d'utilisateurs qui découvrent une extension non fonctionnelle en pratique.

Redéfinition des dépendances de nombreux paquets de git vers git-core. Plus de 200 paquets souhaitent utiliser le binaire git et ont une dépendance envers ce paquet éponyme alors qu'il est fourni en réalité par le paquet git-core. Ce qui implique une dépendance excessive envers 60 autres paquets inutiles dans ce contexte. Cela devrait entre autre réduire les ressources nécessaires pour générer certains paquets.

La communauté francophone

L'association

Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.

Nous lançons donc un appel à nous rejoindre afin de nous aider.

L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.

Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

• Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
• Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
• Concevoir des goodies ;
• Organiser des évènements type Rencontres Fedora dans votre ville.

Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.

Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuelles chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l'avons mis en place en visioconférence sur Jitsi.

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les cinq années de retard accumulées sur le sujet.

Le moins que l'on puisse dire, c'est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège, Sylvain Réault et les autres contributeurs et relecteurs pour leurs contributions.

La synchronisation du travail se passe sur le forum.

Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.

Comment se procurer Fedora Linux 42 ?

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

Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.

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

De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 42.

Dans le cadre des 20 ans de Fedora-fr (et du Projet Fedora en lui-même), nous – 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 la chance d’avoir suffisamment de contributeurs 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 Remi Collet (pseudo remi), empaqueteur du Projet Fedora en particulier concernant l’écosystème PHP.

Sommaire

• Conclusion

Peux-tu présenter brièvement ton parcours ?

40 ans, c’est long !

J’ai découvert l’informatique à une époque préhistorique où l’on travaillait sur des terminaux (texte) connectés à de gros systèmes avec des langages oubliés (Cobol…). Ensuite j’ai eu la chance de voir les choses changer.

Travaillant pendant 20 ans dans une grande administration française, et parallèlement dans une université à la gestion du matériel pédagogique. J’ai vu arriver les ordinateurs personnels, les premiers réseaux locaux, GNU, Linux, Windows, Internet… Rapidement à l’université (veille technologique) et progressivement dans le monde professionnel. Les solutions OpenSource ont toujours été au cœur de mon activité, et la contribution un but personnel.

Au départ développeur, je suis aussi devenu administrateur système et réseau.

Je travaille désormais chez Red Hat comme développeur, principalement chargé de PHP.

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

Lorsque j’ai migré mon ordinateur personnel sous Linux il y a plus de 20 ans, j’ai passé beaucoup de temps sur les forums, pour apprendre des autres et aider les nouveaux.
Cela a été très formateur.

Ensuite je me suis investi dans la maintenance de paquets RPM pour mes besoins et pour partager. Et je me suis concentré sur le monde PHP.

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

J’ai commencé avec Red Hat Linux 5 (1997), qui est devenu Fedora Core, puis Fedora. Au départ c’est le hasard d’un serveur livré avec un CD. Et depuis j’ai toujours été fidèle à l’une des premières distributions majeures.

Pourquoi contribuer à Fedora en particulier ?

Parce que c’est “la” distribution où les choses changent.

Peux-tu préciser les éléments qui confirment cela de ton point de vue ?

L’exemple le plus marquant est sans doute “systemd” qui a provoqué lors de sa sortie un débat technique très vif, mais qui est désormais sur toutes les distributions (ou presque).

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

Principalement PHP et de nombreux projets autour (extensions, bibliothèques, applications…).

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Oui, depuis 1997 avec l’installation d’un serveur d’accès à Internet. Et aujourd’hui sur tous mes serveurs et postes de travail.

Tu as été recruté par Red Hat alors que tu étais déjà dans la communauté de Fedora, comment cela s’est passé ?

Depuis la fusion de Fedora Core + extras (2007), j’étais devenu le mainteneur du paquet PHP. Donc quand Red Hat a cherché à recruter un mainteneur spécifique pour PHP (2012), j’étais le mieux placé.

Ils t’ont contacté ou tu as postulé ?

Ils m’ont contacté (cooptation), ce qui tombait bien puisque je cherchais un nouvel emploi.

Est-ce que la contribution à Fedora a été un élément déterminant dans le processus ?

Clairement oui, ainsi que mon implication dans PHP, en amont.

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

Non.
Je contribuais au Projet Fedora avant de rejoindre Red Hat, et si j’ai la chance de pratiquer ma passion (l’OpenSource) dans mon travail, je continue aussi en dehors. Ma position m’a aussi permis d’augmenter mes contributions sur les autres projets.

Par contre, aujourd’hui je cherche à maintenir un équilibre afin de garder une vie privée et sociale saine.

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

Non (en dehors du temps), et heureusement. Fedora est avant tout un projet communautaire.

Tu es actif au sein de SIG PHP, quel est le rôle de cette équipe de travail et de ton activité dans cette équipe ?

Ce groupe n’a jamais été très actif, et je suis désormais pratiquement seul.

Tu es également contributeur au sein du projet PHP lui-même, quelle est la nature de ton travail pour ce projet ?

Je contribue régulièrement au code, surtout sur des corrections de défauts rapportés par les utilisateurs de mon dépôt, de Fedora ou de RHEL. Je maintiens aussi quelques extensions (zip, mailparse, rpminfo…). Je participe aussi activement au processus de publication des nouvelles versions (QA avant annonce).

Quels bénéfices retires-tu de travailler sur les deux aspects du projet PHP à savoir upstream mais aussi sur la conception de ces paquets ?

Il me semble indispensable de communiquer entre l’amont (le projet PHP) et l’aval (le Projet Fedora). Être impliqué dans les 2 projets simplifie énormément les choses. Et évidement, il est plus facile de faire évoluer un projet lorsqu’on y contribue activement.

Quelles simplifications cela comporte plus en détail selon toi ?

Lorsqu’un utilisateur de Fedora (ou de mon dépôt) signale un bug, il est plus simple de le corriger en étant contributeur, soit directement, soit par le dialogue avec les autres développeurs.

De même pour les évolutions de la distribution qui peuvent avoir un impact sur PHP (exemple: l’intégration à systemd).

Et la réciproque est vraie pour les évolutions du projet qui peuvent affecter la distribution (exemple: la suppression d’extension ou l’ajout de nouvelles fonctionnalités nécessitant de nouveaux outils).

Être actif dans une communauté permet d’être connu et reconnu et donc d’être écouté.

Tu as aussi l’un des dépôts externes les plus populaires et actifs de Fedora centré sur PHP, pourquoi as-tu créé ce dépôt ? Pourquoi tu continues à l’alimenter alors que le projet Fedora fourni déjà PHP ?

Ce dépôt existe depuis 2005 et me permettait de partager mon travail avant de contribuer à Fedora.

Aujourd’hui c’est là que je prépare les évolutions avant qu’elles soient intégrées dans Fedora (puis dans CentOS Stream, puis dans RHEL). Par exemple PHP 8.3 présent dans Fedora 40 était dans mon dépôt depuis presque 1 an (Juin 2023, version 8.3.0alpha1)

Alors que Fedora fournit une seule version de PHP et une cinquantaine d’extensions, mon dépôt propose 5 versions (même 10 pour EL), ~150 extensions et 2 modes d’installation.

Pourquoi ne pas utiliser le système de COPR pour ce travail ?

Copr est très intéressant pour les petits projets. Dans mon cas, ce sont des milliers de paquets. Et Copr n’est pas adapté pour les modules, ni pour les quelques paquets non libres que je maintiens (ex: Oracle).

Peux-tu expliquer l’importance du mainteneur de paquet dans la distribution ? Quels choix il faut effectuer, les difficultés techniques rencontrées, etc.

C’est celui qui essai de coordonner les projets amont / aval et les utilisateurs en essayant de satisfaire des besoins parfois incompatibles de stabilité, de compatibilité, d’innovation.

Les “Modules” de Fedora étaient censés être un pilier de Fedora.next pour fournir différentes versions des piles technologiques, comme PHP, pour une version donnée de Fedora. Maintenant que c’est abandonné, peux-tu expliquer les raisons derrière cet échec ? Pour un empaqueteur, quelles ont été les difficultés derrière ?

https://blog.remirepo.net/post/2024/03/29/DNF-5-and-Modularity. Je retiendrais que ce projet répondait avant tout à un besoin de distribution entreprise qui n’est pas vraiment utile à Fedora avec un cycle de version très rapide (6 mois).

La complexité du système de construction a peut-être été une raison de son échec.

Tu as aussi écrit la documentation française pour faire ses propres paquets RPM et tu as aidé de nombreux francophones à réaliser leurs premiers paquets, qu’est-ce qui t’intéresse à guider les débutants dans cette activité ?

Le partage.
Accompagner un débutant est toujours passionnant, humainement et techniquement. Cela permet aussi de répondre à des questions qu’on ne se pose pas forcément, et donc de se remettre en cause.

Les paquets traditionnels ne sont plus l’unique voie d’avoir un logiciel qui tourne sous Fedora. Avec Flatpak, Snap ou des solutions tels que Docker / Podman cela devient possible de s’en affranchir. Comment vois-tu l’évolution des paquets au sein d’une distribution dans Fedora ? Que penses-tu de ces évolutions ?

Avant on cherchait à créer une distribution cohérente ou chaque composant était partagé et utilisé par les autres (une sorte de Lego).

Aujourd’hui, et je le regrette, beaucoup ont abandonné cet objectif et beaucoup de projets préfèrent embarquer tous les composants qu’ils utilisent.

C’est le cas de PHP avec “composer”, de langages comme Rust où la notion de bibliothèques partagées n’existe même plus. Flatpack / Snap n’en sont qu’un développement extrême.

N’est-ce pas aussi parce que cela résout certaines problématiques liées à la rigidité des paquets qui rendent notamment la cohabitation de versions différentes délicates ou de rendre l’environnement de travail plus modulaire ?

Je pense que cela ne résout rien. On sait parfaitement installer plusieurs versions d’une bibliothèque simultanément.

Disons que c’est la solution de facilité, on n’essaie même plus de faire propre. Sans parler des projets qui embarquent des copies modifiées, sans que les modifications soient reversées ou discutées.

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 ?

La communauté Fedora est composée de gens passionnés. La passion entraine parfois des positions excessives et des discussions sans consensus possible.
La communauté des contributeurs a tué de beaux projets, comme les « Softwares Collections » ou les “modules”. Je trouve cela dommage.

Peux-tu expliquer ce que sont les Software Collections et pourquoi cela n’a pas abouti ? Quelles différences avec les modules notamment ?

Les Software Collections permettent une méthode standard d’installation de plusieurs versions d’une application sans conflit espace de nom différent, installation sous /opt et sans risque d’altération du système de base.

Le projet ayant été développé par Red Hat pour les besoins de sa distribution Entreprise il a provoqué un vif débat technique (ex: non respect de la FHS, ce qui a été corrigé par la suite) et a même provoqué l’épuisement et le départ de 2 membres du FPC.

La complexité d’utilisation (activation de la SCL) a aussi été des raisons de leur détestation.

Ce besoin étant quasi inexistant pour Fedora, personne n’a eu la force d’améliorer la solution qui a été abandonnée.

Les modules permettent de fournir plusieurs versions alternatives d’une application, mais sans permettre une installation simultanée. Fonctionnellement c’est comme si chaque version est disponible dans un dépôt différent qu’il suffit d’activer.

À 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 ?

La passion justement, qui reste un moteur indispensable. S’il n’y a plus de passion, plus de plaisir, autant arrêter (j’ai abandonné quelques projets pour cela).

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

La communauté Fedora est surtout composée de contributeurs. D’autres distributions ont une communauté d’utilisateurs et sont excellentes pour leur promotion.

Je n’ai malheureusement pas d’idée magique pour augmenter la communauté Fedora-Fr.

Je pense aussi que les contributeurs français sont souvent actifs dans la communauté globale (en anglais) plutôt que dans la communauté française.

Trouves-tu que c’est spécifique à la communauté francophone ?

Je ne sais pas, je ne connais pas trop les autres communautés, mais je rencontre beaucoup de nationalités différentes dans la communauté anglophone.

Merci Remi pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur l’empaquetage de 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.

À dans 10 jours pour un entretien avec Emmanuel Seyman, ancien président de Borsalinux-fr et actuel empaqueteur dans l’écosystème du langage Perl.

En ce mardi 18 mars 2025, la communauté du Projet Fedora sera ravie d’apprendre la disponibilité de la version bêta de Fedora Linux 42.

Malgré les risques concernant la stabilité d’une version bêta, 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 42 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 15 ou le 22 avril.

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 48 ;
• L’environnement de bureau Xfce bénéficie de la version 4.20 ;
• L’environnement de bureau LXQt passe à la version 2.1 ;
• Le logiciel d’installation d’Anaconda devient une application Wayland native ;
• Anaconda a enfin une interface web UI pour l’étape du partitionnement ;
• Anaconda en profite pour également être une web UI par défaut pour Fedora Workstation ;
• L’édition KDE Plasma devient une édition à part entière, étant mise au même niveau que Fedora Workstation avec l’environnement GNOME ;
• L’écran de chargement lors du démarrage plymouth utilise simpledrm pour réduire l’attente qu’un GPU soit disponible ;
• L’environnement de bureau COSMIC bénéficie de sa propre édition Spin ;
• Activation de la mise à jour automatique par défaut pour la version atomique de KDE Plasma nommée Kinoite.

Gestion du matériel

• Amélioration de la prise en charge des webcams basées sur le protocole MIPI au lieu de USB dans les ordinateurs portables x86 ;
• L’Intel Compute Runtime, qui prend en charge notamment le fonctionnement de l’API OpenCL pour les processeurs Intel, a été mise à jour vers la version 24.39 qui signifie également une non prise en charge des processeurs d’avant 2020 (à partir de la 12ᵉ génération) ;
• Introduction de la pile Intel SGX pour permettre son utilisation dans le futur pour améliorer l’isolation et la protection mémoire en particulier pour les machines virtuelles ;
• Intégration du projet FEX dans les dépôts pour permettre l’exécution des programmes x86 / x86_64 depuis les architectures AArch64 ;
• L’installateur Anaconda utilise la norme GPT par défaut pour la table de partitionnement pour les architectures PPC64LE et s390x, l’architecture x86_64 et Aarch64 ayant déjà sauté le pas avec Fedora Linux 37 ;
• Les versions atomiques n’auront plus d’images compatibles avec l’architecture PPC64LE ;
• Le paquet du logiciel Zezere qui sert à automatiser l’installation et la configuration de systèmes IoT a été retiré des dépôts.

Internationalisation

• Mise à jour de l’entrée de saisie IBus 1.5.32 ;
• Son aide à la saisie pour le chinois ibus-libpinyin est aussi mise à jour à la version 1.16 ;
• Proposition d’une nouvelle aide à la saisie vocale avec Ibus Speech to Text via le paquet ibus-speech-to-text qui permet de faire de la reconnaissance vocale en local.

Administration système

• Les répertoires /usr/bin et /usr/sbin sont fusionnés ;
• DNF5 va proposer à l’utilisateur de supprimer les clés GPG qui ont expiré, ou qui ont été révoquées, évitant de devoir le faire à la main avec la commande rpmkeys --delete ;
• La commande fips-mode-setup a été retirée du paquet crypto-policies qui permet de rendre dynamiquement son système compatible avec les exigences du gouvernement américain concernant les modules cryptographiques. Cette option doit être activée lors de l’installation par d’autres moyens maintenant ;
• Le navigateur de fichiers pour Cockpit cockpit-navigator est remplacé par cockpit-files ;
• Les éditions dérivées de Fedora Workstation auront par défaut le pare-feu configuré avec l’option IPv6_rpfilter=loose, ce qui suit la politique appliquée pour l’IPv4 depuis Fedora 30 ;
• Ajout du paquet bpfman pour le déploiment et la gestion des programmes eBPF dans le système ;
• Réduction du nombre de règles SELinux liées au type unlabeled_t qui mènent à ne pas enregistrer dans le journal d’audit des erreurs détectées ;
• Mise à jour de l’outil de gestion de configuration Ansible à la version 11 ;
• Le serveur de proxy inverse Apache Traffic Server évolue vers sa 10ᵉ version ;
• La version de compatibilité PostgreSQL 15 a été retirée, PostgreSQL 16 reste la version par défaut ;
• Les utilitaires liés au projet OpenDMARC ont été mis dans des paquets individuels au lieu du paquet opendmarc qui les fournissait tous ;
• L’agent pam-ssh-agent a été supprimé des dépôts.

Développement

• La chaîne de compilation GNU bénéficie de GCC 15, binutils 2.44, glibc 2.41 et gdb 15 ;
• La chaîne de compilation LLVM progresse à la 20ᵉ version ;
• La boîte à outils Python nommée Django utilise la version 5.x ;
• Mise à jour du langage Go vers la version 1.24 ;
• Le langage Ruby brille avec la version 3.4 ;
• Le langage de programmation PHP s’impose de tout son poids à la version 8.4 ;
• Le compilateur du langage fonctionnel Haskell, GHC, passe à la version 9.8 et sa suite de paquets Stackage utilise la version 23 ;
• Le langage de programmation fonctionnel Idris dispose d’une mise à jour majeure vers sa 2ᵉ version ;
• Le langage de scripts Tcl/Tk a été mis à jour vers la 9ᵉ version ;
• La bibliothèque de calcul scientifique en Python NumPy passe à la version majeure 2 ;
• L’outil de développement de paquets Python Setuptools a été mis à jour vers la version 74 ;
• Mise à jour de la bibliothèque de compression zlib-ng à la version 2.2.x ;
• La bibliothèque graphique SDL utilise la version 3 pour assurer la compatibilité avec sa version 2 dorénavant ;
• Les anciennes versions de OpenJDK pour le langage Java à savoir 8, 11 et 17 ne sont plus fournies par les dépôts de Fedora mais devront être installés via un dépôt tiers tel que Adoptium Temurin dont le paquet adoptium-temurin-java-repository permet son activation ;
• Le paquet de compatibilité Python pour la version 3.8 a été retiré ;
• La bibliothèque Rust zbus version 1 a été supprimée, la version 4 ou supérieure reste proposée dans les dépôts ;
• La bibliothèque de compatibilité entre Rust et Python, PyO3, se voit retirer les anciennes versions 0.19, 0.20, et 0.21 ;
• L’utilitaire d’exécution des tests unitaires en Python python-pytest-runner est déprécié et sera supprimé dans un futur proche ;
• La bibliothèque de compatibilité entre GTK3 et Rust est marquée comme dépréciée et sera supprimée dans une prochaine version.

Projet Fedora

• Fedora Linux proposera des archives permettant d’être installé avec Windows Subsystem for Linux ;
• Les paquets RPM peuvent bénéficier de la fonction systemd sysusers.d pour créer des utilisateurs dédiés lors de l’installation des paquets RPM ;
• Les mises à jour de Fedora CoreOS passent de OSTree à OCI ;
• Les fichiers Kickstart seront distribués également comme des artéfacts OCI ;
• Activation par défaut de composefs pour les images atomiques bureautiques de Fedora Linux ;
• L’utilitaire edk2 est compilé avec des options de sécurité supplémentaires pour améliorer la sécurité des machines virtuelles reposant sur l’UEFI ;
• Les images live de Fedora Linux utilisent le système de fichiers EROFS en lieu et place de SquashFS ;
• Ajout d’un générateur de dépendances pour les extensions de GNOME Shell, permettant de lier la version de l’extension avec celle de gnome-shell à partir du fichier metadata.json de l’extension ;
• Redéfinition des dépendances de nombreux paquets de git vers git-core.

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 bêta 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 41 ou 40 sur votre machine, vous pouvez faire une mise à niveau vers la bêta. 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 42.

Bons tests à tous !

En ce mardi 29 octobre 2024, les utilisateurs du Projet Fedora seront ravis d’apprendre la disponibilité de la version Fedora Linux 41.

Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• La communauté francophone
  • L’association
  • La documentation
• Comment se procurer Fedora Linux 41 ?

Expérience utilisateur

Passage à GNOME 47. Cette nouvelle version de l’environnement phare de Fedora propose de nombreuses améliorations. Tout d’abord, il est maintenant possible de personnaliser une couleur "accentuée" (accent color) qui influencera la couleur de nombreux éléments graphiques comme des boutons. Cela intègre donc un changement en place chez Ubuntu depuis quelques années. Pour ceux disposant de petits écrans, certains boutons et autres icônes sont agrandies pour rendre leur interaction plus aisée dans ce contexte.

L’interface a été en partie remaniée au niveau des boîtes de dialogue pour rendre leur interaction plus simple notamment avec des petits écrans avec des boutons plus gros et plus espacés entre eux. Et bien sûr ces boutons tiennent compte maintenant de la couleur accentuée explicitée précédemment. L’interface pour ouvrir ou sauvegarder un fichier repose maintenant sur le code du navigateur de fichiers nommé Fichiers plutôt que d’utiliser un code indépendant jusqu’ici. Cela simplifie la maintenance mais permet surtout de fournir l’ensemble des fonctionnalités du navigateur de fichiers pour cette tâche. Par exemple il est possible de renommer des fichiers depuis cette interface, de changer l’ordre d’affichage en vue icônes, prévisualiser les fichiers sans les ouvrir, etc. Par ailleurs, le navigateur de fichiers s’améliore aussi. Les périphériques réseaux sont maintenant classifiés permettant d’identifier les ressources où on est déjà connecté, qu’on a précédemment utilisé et les autres. L’ensemble des disques durs internes sont également affichés dans la barre latérale et groupés ensemble pour rendre cela plus accessible et facile d’utilisation. Il est possible également de supprimer les dossiers par défaut dans la barre latérale pour faire de la place si on le souhaite. Et quelques autres changements plus mineurs.

Dans la configuration de l’interface, il est possible via le menu Accessibilité de configurer le changement automatique de focus d’une fenêtre à une autre par le simple survol de la souris. Option désactivée par défaut. De même lors de l’ajout de nouvelles dispositions clavier, la prévisualisation de cette disposition peut être effectuée avant de la sélectionner pour s’assurer que c’est bien celle souhaitée. De manière générale, l’affichage des préférences est plus cohérente dans le choix des éléments graphiques pour les représenter à travers l’interface.

Les comptes en ligne progressent également, les informations IMAP ou SMTP sont préremplies en se basant sur l’adresse électronique. La synchronisation du calendrier, des courriels et des contacts a été ajoutée pour les comptes Microsoft 365 pendant que la configuration d’un nouveau compte WebDAV permet de découvrir les services accessibles depuis ce compte pour faciliter l’expérience utilisateur.

Le navigateur web maison n’est pas en reste et propose quelques améliorations dont le pré remplissage des formulaires en se basant sur les entrées précédentes ce qui est disponible dans de nombreux navigateur. L’option peut être désactivée dans les préférences si nécessaire. Les marques pages ont été aussi remaniés en étant affichés dans un volet latéral et en proposant une barre de recherche intégrée pour retrouver celui qu’on souhaite. Le navigateur peut afficher le nombre de trackers publicitaires qui ont été bloqués. Malheureusement la synchronisation des éléments via Firefox Sync n’est plus possible en ce moment à cause d’un changement dans la procédure d’authentification par Mozilla.

L’application calendrier a été également améliorée avec par exemple une icône de cadenas qui s’affiche pour les événements qui sont en lecture seule. La mise en page est plus cohérente notamment dans l’espacement entre les éléments visuels. L’importation ou l’édition d’événements gèrent mieux les calendriers cachés ou en lecture seule. L’application de cartographie a été aussi légèrement améliorée en utilisant les cartes vectorisées par défaut et en proposant les trajets en transport en commun en exploitant le service Transitous plutôt qu’une solution commerciale.

Pour les amateurs d’enregistrement de leur écran en vidéo, cette tâche peut être effectuée dans la mesure du possible avec de l’accélération matérielle ce qui diminue la consommation d’énergie et améliore les performances du système dans ce cadre. Dans la même veine, le rendu effectué par la bibliothèque graphique GTK se fait via Vulkan dorénavant ce qui améliore les performances en particulier pour les machines plus anciennes et avec moins d’effets visuels indésirables due à la lenteur de certaines opérations. Dans la même veine, il y a une amélioration des performances des applications vidéos, photos et du navigateur web maison par la réduction quand c’est possible du nombre de copies en mémoire des données d’une vidéo ou d’une image.

Pour ceux qui ont accès à leur session à distance, il est dorénavant possible de rendre cette session persistante. En cas de déconnexion il est possible de revenir plus tard et de retrouver la session dans l’état où elle était.

Pour les utilisateurs avancés, il y a des changements expérimentaux qui sont proposés. Si vous souhaitez utiliser la mise à échelle fractionnaire de l’interface pour les applications utilisant X11 via XWayland, vous pouvez l’activer via la commande suivante :

$ gsettings set org.gnome.mutter experimental-features '["scale-monitor-framebuffer", "xwayland-native-scaling"]'

L’environnement de bureau léger LXQt passe à la version 2.0. Cette mise à jour importante est essentiellement technique avec un port complet vers la bibliothèque graphique Qt 6 au lieu de Qt 5 qui n’est bientôt plus maintenue. La prise en charge de Wayland est disponible à titre expérimental, cela devrait être stabilisé pour la version 2.1 à venir.

L’éditeur d’image GIMP utilise la branche de développement qui deviendra la version 3. Cette décision a été prise car GIMP devenait la raison principale pour maintenir le langage Python 2.7 dans la distribution qui n’est plus maintenue depuis quelques années. Alors que GIMP 3 devrait sortir sous peu, il a été décidé de prendre potentiellement un peu d’avance pour permettre de supprimer cette dépendance assez lourde et complexe de Fedora.

Outre cette décision, cette version de l’application propose entre autres une meilleure gestion des couleurs avec notamment la visualisation, l’import ou l’export d’images avec la colorimétrie CMJN. Les tablettes graphiques ont une expérience utilisateur améliorée avec notamment la possibilité de personnaliser l’action des boutons de ce matériel sous Wayland, et la prise en charge des écrans avec une définition HiDPI est aussi améliorée. L’édition non destructive est également possible pour séparer l’application des effets des calques de l’image pour permettre de revenir dessus plus tard. Si on le souhaite, un calque peut se redimensionner automatiquement lors de son édition lors d’un dessin par exemple. Et bien d’autres changements.

Le gestionnaire de listes de tâches Taskwarrior évolue à la version 3. Cette version a surtout changé la manière de stocker les données sauvegardées et n’est pas rétrocompatible avec l’ancienne méthode. Il est donc nécessaire d’exporter les tâches avec l’ancienne version par l’usage de la commande task export et de les importer avec la nouvelle version avec la commande task import rc.hooks=0. La tâche de sauvegarde est aussi confiée à un nouveau module TaskChampion écrit en Rust.

La mise à jour du cœur des systèmes atomiques de bureau peut se faire sans droits administrateurs, mais pas les mises à niveau de celui-ci à savoir par exemple passer d’une version Fedora Linux Silverblue 40 à Fedora Linux Silverblue 41. Cela était déjà le cas pour Fedora Silverblue avec l’usage de GNOME Logiciels mais a été de fait généralisé. L’objectif est de simplifier la procédure de mise à jour du système, qui dans le cadre d’un système atomique est considéré comme plus sûre que dans un système traditionnel de par sa conception qui permet facilement de revenir à l’état précédent et par la faible quantité de logiciels installés dans le cœur du système.

Les autres opérations ne sont pas considérées à ce stade car trop risquées pour être confiées à un simple utilisateur. Pour certaines opérations le mot de passe administrateur sera systématiquement demandé telles que l’installation d’un nouveau paquet local, la mise à niveau complet du système (qui consiste en une opération de rebase avec une autre branche de travail), ou changer les paramètres du noyau. Pour d’autres comme l’installation d’un paquet provenant d’un dépôt, la mise à jour, le retour dans un état précédent ou l’annulation d’une commande peut se faire sans demander systématiquement le mot de passe, comme lors de l’usage de commandes via sudo si les opérations ne sont pas trop espacées.

Mise à disposition des images Spin KDE Plasma Mobile et Fedora Kinoite Mobile. L’objectif est de fournir une image native avec cet environnement qui fonctionne aussi bien pour téléphone que pour les tablettes ou petits ordinateurs portables 2-1 avec possibilité de détacher l’écran tactile du clavier.

De même le gestionnaire de fenêtres en mode pavant Miracle exploitant Wayland est proposé dans Fedora et bénéficie de son propre Spin. Cette interface moderne prend en charge aussi les fenêtres flottantes, prend en charge les dernières montures de Wayland tout en permettant l’usage des pilotes propriétaires de Nvidia. Il consomme également peu de ressources ce qui le rend intéressant dans l’usage de machines peu performantes ou anciennes tout en exploitant une pile graphique très moderne et flexible.

L’installation de Fedora Workstation se fera avec le protocole d’affichage Wayland uniquement, les sessions GNOME X11 restent disponibles et installables après. Cela suit l’effort entrepris depuis longtemps de faire de Wayland le protocole d’affichage par défaut de Fedora et par l’abandon progressif de X11 par GNOME également. L’état actuel du système permet de franchir ce cap par défaut ce qui allège également un peu le média d’installation. Cependant pour ceux qui veulent toujours utiliser GNOME avec X11 après l’installation pour différentes raisons, il reste possible d’installer les paquets gnome-session-xsession et gnome-classic-session-xsession depuis les dépôts officiels.

Gestion du matériel

L’installation du pilote propriétaire de Nvidia via GNOME Logiciels est compatible avec les systèmes utilisant l’option Secure Boot. Ce mode de sécurité s’assure que tous les éléments de la chaine de démarrage de la machine sont signés avec une des clés cryptographiques autorisées. L’objectif est d’éviter qu’une tierce personne puisse modifier un de ces composants dans le dos d’un utilisateur afin de réaliser une attaque plus tard. Le chargeur de démarrage GRUB, le noyau Linux et ses pilotes sont évidemment concernés, et installer le pilote propriétaire de Nvidia qui n’est pas signé pouvait rendre la machine impossible à démarrer.

Même si Fedora ne fournit pas ce pilote, car il est non libre, l’objectif reste d’avoir un système fonctionnel et simple à utiliser. Dans ce contexte, GNOME logiciels permet d’outre passer cette limitation en utilisant l’outil mokutil pour auto signer le pilote Nvidia. L’utilisateur devra saisir un mot de passe à l’installation du paquet, et au redémarrage suivant cet outil sera affiché pour confirmer la clé de sécurité et ainsi autoriser le chargement du dit pilote sans encombre.

Prise en charge des caméras MIPI pour les systèmes utilisant Intel IPU6 qui concerne de nombreux ordinateurs portables actuels. En effet, de nombreux modèles utilisent le bus MIPI CSI2 au lieu du traditionnel USB UVC qui était la norme jusqu’à présent. En effet ce protocole permet des bandes passantes plus élevées, en consommant moins d’énergie et plus facile à intégrer. Sauf que la prise en charge de ce bus n’était pas pleinement gérée, car les images envoyées sont un peu brutes et nécessitent des traitements notamment concernant la balance des blancs ou le dématriçage de l’image ou le contrôle pour l’exposition et le gain. Cela est complexe, car chaque caméra a ses propres caractéristiques qui nécessitent une approche au cas par cas en espace utilisateur. Un travail d’intégration a été fait entre le noyau Linux, libcamera, pipewire et Firefox pour rendre cela possible. Le noyau Linux fourni l’API de base et un pilote pour chaque type de modèles, avec un pilote commun pour la prise en charge du protocole en lui-même. Le flux vidéo est récupéré par libcamera qui applique des traitements tels que le dématriçage en prenant en compte le modèle considéré, qui envoie le flux vidéo obtenu par pipewire vers le navigateur Firefox.

L’installateur Anaconda prend en charge le chiffrement matériel des disques via le standard TCG OPAL2 disponible sur certains péripériques SATA ou NVMe, mais cela nécessite de passer via un fichier kickstart pour personnaliser l’installation. L’outil cryptsetup n’a pris en charge ce standard que très récemment, l’objectif est de fournir les arguments --hw-opal-only ou --hw-opal à cet utilitaire dans le fichier kickstart. Le premier argument n’active que le chiffrement matériel, ce qui est recommandé uniquement pour des périphériques où l’usage du CPU pour cette tâche nuirait grandement aux performances, alors que le second utilise un chiffrement matériel et logiciel. Il n’est pas prévu de fournir cette fonctionnalité par défaut et restera pendant un moment une option pour les utilisateurs avancés, car la sécurité de l’ensemble dépend de la qualité des firmwares de ces périphériques de stockage et qui doivent être maintenus à jour dans le temps ce qui n’est pas garanti.

Utilisation par défaut de l’outil tuned au lieu de power-profiles-daemon pour la gestion de l’énergie de la machine. C’est l’outil qui permet notamment de passer du mode économie d’énergie à performance pour moduler la puissance du CPU en fonction de la consommation d’énergie souhaitée, ce qui est très appréciable sur les ordinateurs portables en particulier. Cependant power-profiles-daemon est très simple, en dehors de ces modes très génériques et d’appliquer cela sur les CPU ou les plateformes matérielles supportées, il ne permettait une configuration plus fine ou l’ajout de modes personnalisées. Les utilisateurs avancés étaient contraints d’installer un utilitaire additionnel comme tuned pour cela. Il a été ajouté un paquet tuned-ppd qui fourni une API DBus compatible avec l’interface de power-profiles-daemon, ainsi les applications telles que le centre de configuration de GNOME, Plasma ou Budgie peuvent s’en servir directement à la place sans régression, tout en permettant aux utilisateurs avancés d’aller plus loin s’ils le souhaitent en modifiant le contenu de /etc/tuned/ppd.conf comme en changeant les réglages périphérique par périphérique.

Mise à jour de ROCm 6.2 pour améliorer la prise en charge de l’IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d’AMD. Il fournit entre autres des nouveaux composants tels que Omniperf pour l’étude et l’analyse de performance, Omnitrace pour tracer l’exécution des fonctions sur le CPU ou le GPU, rocPyDecode comme implémentation de l’API rocDecode en Python pour l’analyse des données de profilage faits avec cet outil en C ou C++ ou ROCprofiler-SDK pour identifier les points bloquants de performance. Il prend en charge également les dernières versions des outils PyTorch et TensorFlow.

L’outil de développement et de débogage des tables ACPI nommé acpica-tools ne prend plus en charge les architectures gros boutistes tels que s390x. En effet, ce standard qui est conçu pour les machines petits boutistes n’a pas beaucoup de sens pour cette architecture, les paquets qui en avaient besoin pour s390x ont de moins en moins cette dépendance et comme l’usage de cette architecture reste faible surtout pour cet usage, il a été décidé de retirer la prise en charge de cette spécificité. 49 correctifs sur 69 concernant ce paquet sont liés à cette prise en charge, car le projet n’a jamais voulu les adopter par manque d’intérêt, ce qui impliquait beaucoup de test et de développement ralentissant la fréquence des mises à jour du paquet. Ces correctifs sont maintenant supprimés.

PHP ne prend plus en charge les processeurs x86 32 bits. Il n’y avait déjà plus de paquets PHP 32 bits dans les dépôts, mais PHP était toujours compilé pour permettre à d’autres dépendances de l’être pour cette architecture. Des restrictions ont été ajoutées à ces dépendances pour que cela ne soit plus bloquant. PHP était souvent utilisé dans le cadre de tests ou pour gérer des plugins ou extensions qui pouvaient être désactivées. L’architecture x86 32 bits n’est pour rappel plus pris en charge par Fedora depuis quelques années maintenant, ces paquets ne sont utilisables que sur des machines x86 64 bits pour des raisons de compatibilité. Ce nettoyage permet en contrepartie un gain de temps machine et de développeurs, car il n’y a plus à gérer ce cas de figure.

Internationalisation

Le gestionnaire d’entrées IBus par défaut pour la langue traditionnelle chinoise de Taiwan passe de ibus-libzhuyin à ibus-chewing. En effet la bibliothèque chewing sous-jacent semble avoir une communauté dynamique qui fournit une bonne maintenance contrairement à libzhuyin qui n’est d’ailleurs pas maintenu en ce moment par un locuteur de cette langue ce qui pose quelques difficultés. Le code semble également mieux organisé et plus maintenable.

Administration système

Le gestionnaire de paquet dnf est mis à jour vers sa 5ᵉ version. Cette version écrite en C++ au lieu de Python est bien plus rapide à l’usage et consomme moins d’espace disque et requiert moins de dépendances pour tourner, l’ensemble est 60% plus léger sur le disque. Par ailleurs dnf5daemon remplace PackageKit comme couche de compatibilité pour dnf dans GNOME Logiciels, ce qui permet notamment le partage des caches entre l’interface console et l’interface graphique évitant un gaspillage d’espace disque et de bande passante. Niveau performance, certaines opérations sont maintenant parallélisées comme le téléchargement et le traitement des données des dépôts qui doit être jusqu’à deux fois plus rapide. Les plugins sont également mieux intégrés ce qui en simplifie leur installation et leur maintenance. Cependant certains plugins n’ont pas été encore portés, vous pouvez suivre l’avancement pour ceux qui manquent à l’appel. Mais cela ne devrait concerner que peu d’utilisateurs. Certaines options de la ligne de commande n’existent plus par ailleurs, cela vous sera rappelé si vous les invoquiez. L’historique des précédentes transactions de paquets comme les mises à jour ou installations ne sont pas compatibles entre l’ancienne et la nouvelle version, vous ne pourrez donc pas voir vos anciennes transactions pour les annuler par exemple.

Tandis que la commande rpm utilise la version 4.20. Cette version permet de lister ou de supprimer les clés pour signer les paquets via la commande rpmkeys alors que l’outil rpmsign permet de signer les paquets avec l’algorithme ECDSA. La commande rpm elle-même permet d’afficher une sortie en format JSON, en plus du format XML déjà pris en charge depuis longtemps. Un nouveau plugin rpm-plugin-unshare apparaît pour empêcher à des scripts d’installation de faire certaines opérations sur le système de fichiers ou via le réseau pour des raisons de sécurité. Côté création de paquet, l’introduction de la directive BuildSystem est sans doute la plus importante pour permettre de définir de manière unique et générique la création de paquets basés sur des outils communs tels que autotools ou cmake. L’empaqueteur n’aurait pas besoin de rappeler pour ces outils courants chaque étape pour la création du paquet, sauf en cas de particularité, ce qui permet une meilleure maintenance et cohérence au sein de la distribution par exemple.

Les systèmes Fedora atomiques de bureau et Fedora IoT disposent de bootupd pour la mise à jour du chargeur de démarrage. La mise à jour du chargeur de démarrage au sein d’un système atomique n’est pas trivial, car ce n’est pas une opération facile à fiabiliser. Par conséquent rpm-ostree ne prenait pas cela en charge, et c’est pourquoi bootupd a été créé et est maintenant intégré dans ces versions. Il était déjà présent depuis quelque temps sur la version CoreOS ce qui a déjà donné un retour d’expérience en conditions réelles. Il peut prendre en charge les systèmes UEFI et BIOS, mais la mise à jour reste une étape manuelle pour être automatisée dans le futur, notamment quand le composant shim sera à jour pour rendre la mise à jour moins risquée sur les systèmes UEFI si la mise à jour est coupée au milieu de l’opération comme lors d’une coupure de courant ou lors d’un plantage. Il permet également de pouvoir bloquer l’usage de versions du chargeur de démarrage plus anciens ayant des failles connues, par l’usage de Secure Boot dbx et le paquet ostree-grub2 pourra être progressivement retiré, ce qui notamment mettra un terme au bogue où chaque déploiement est affiché deux fois dans l’interface de sélection de GRUB et devrait réduire le risque d’avoir certains problèmes lors de la mise à jour du système.

Les images atomiques de Fedora proposent les outils dnf et bootc, ce premier est utilisable dans un contexte de développement pour l’instant mais le second peut commencer à servir à déployer des images du système qui sont bootables. Plus tard il est prévu que dnf puisse remplacer rpm-ostree pour certaines actions. En attendant, en cas d’usage de dnf sur de tels systèmes, le message d’erreur sera plus explicite concernant les outils à employer pour réaliser ces actions. L’objectif est de fournir aux administrateurs systèmes des outils plus familiers pour ces différentes actions tout en ayant un outil clairement identifié pour chaque type de tâches.

Introduction de l’outil fedora-repoquery pour faire des requêtes sur les dépôts comme savoir la version exacte d’un paquet spécifique dans une autre version de Fedora, la date de mise à jour d’un dépôt, ou connaître les paquets qui dépendent d’un paquet spécifique (dépendance inverse donc), etc. Il fonctionne par-dessus dnf concernant cette fonction mais permet de facilement obtenir des informations depuis les dépôts Fedora, CentOS ou EPEL.

La bibliothèque de sécurité OpenSSL n’accepte plus les signatures cryptographiques avec l’algorithme SHA-1. Cet algorithme n’est plus considéré comme sûr, car il devient de plus en plus facile de générer des collisions à la demande. Si vous souhaitez les autoriser à nouveau pour des raisons légitimes, malgré le risque de sécurité, cela reste possible de le faire via la commande

# update-crypto-policies --set FEDORA40

Commande qui devrait être prise en charge pendant quelques versions encore.

Le gestionnaire de réseaux NetworkManager ne prend plus en charge la configuration dans le format ifcfg qui était déjà désuet depuis des années. Cela fait suite aux tentatives progressives d’utiliser massivement le format keyfile. Fedora Linux 33 en l’utilisant comme format par défaut pour les nouveaux profils de connexions, tandis que Fedora Linux 36 a poussé la prise en charge de l’ancien format dans un paquet dédié non installé par défaut nommé NetworkManager-initscripts-ifcfg-rh et enfin Fedora Linux 39 a entamé la conversion automatique vers le nouveau format. Et depuis longtemps NetworkManager ne fait que maintenir ce format, de nombreuses options ou types de connexions n’étant de fait pas possibles avec l’ancien format. Cela permet de préparer la suppression future de la prise en charge de ce format de fichier de NetworkManager lui-même.

Dans la même veine, le paquet network-scripts a été retiré, mettant fin à la gestion du réseau via les scripts ifup et ifdown. Depuis 2018 ces outils sont considérés comme obsolète et soumis à une suppression planifiée future. D’ailleurs le projet officiel ne fait plus une maintenance très active de ces outils.

Les interfaces réseaux pour les éditions Cloud vont utiliser les nouveaux noms par défaut (par exemple enp2s0f0) comme adoptés par les autres éditions il y a des années au lieu de conserver les noms traditionnels (tels que eth0). Cela signifie que le noyau ne recevra plus pour ces systèmes le paramètre net.ifnames=0 pour maintenir cet ancien comportement. Le reste de l’écosystème avait adopté la nouvelle nomenclature avec Fedora… 15 en 2011 ! Ce retard est attribuable à certains problèmes avec certains outils tels que cloud-init avec cette convention de nommage qui ont été résolus à la fin des années 2010 seulement. Ainsi les périphériques auront maintenant une correspondance physique, leur rôle devrait être plus facilement identifiable et limiter le risque de problèmes suite à des changements dynamiques des interfaces.

Le gestionnaire de virtualisation libvirt utilise maintenant par défaut le pare-feu nftables au lieu de iptables pour son interface réseau vibr0. En effet Fedora utilise par défaut nftables maintenant et par ailleurs utiliser iptables signifiait créer des règles nftables sous le capot. Cette transition est faite pour améliorer les performances et réduire le risque d’une suppression accidentelle de règles par une application tierce, car tout sera mis dans les règles associées à la table libvirt_network. iptables sera cependant utilisé si nftables n’est pas présent dans le système et le comportement peut être changé dans le fichier de configuration /etc/libvirt/network.conf.

L’outil Netavark pour gérer la pile réseau des conteneurs, notamment avec podman, utilise également par défaut le pare-feu nftables au lieu de iptables. Les avantages du changement sont assez similaires à ce qui est expliqué au point précédent, les règles associées à l’outil seront mises dans la table dédiée netavark. La possibilité d’envoyer les règles par lot peut améliorer de manière légère le temps de démarrage des conteneurs par ailleurs.

Le gestionnaire de conteneurs Kubernetes a des nouveaux paquets versionnés, permettant d’avoir plusieurs versions en parallèle. Ici les versions 1.29, 1.30 et 1.31 sont proposées avec des noms comme kubernetes1.31. Cela devenait nécessaire car Kubernetes maintient 3 versions sur une période de 4 mois par version seulement ce qui rend nécessaire un tel montage. Cela permet aussi de découpler la version de Kubernetes avec la version de Fedora Linux ce qui facilite la gestion pour les administrateurs.

L’implémentation des interfaces de Kubernetes fait par l’OCI a ses propres paquets cri-o et cri-tools qui sont également versionnés pour pouvoir suivre les versions de Kubernetes.

Développement

Mise à jour de la suite de compilation GNU : binutils 2.42, glibc 2.40 et gdb 15.

Pour la suite d’outils binutils, cela se concentre surtout sur la prise en charge plus étendue des instructions des architectures Aarch64, RISC-V et x86_64. Il gère notamment les registres supplémentaires et les instructions associées proposés par l’évolution de l’architecture x86 avec Intel APX. L’assembleur BPF améliore son interopérabilité avec les outils de LLVM en suivant les mêmes conventions.

La bibliothèque standard C commence une prise en charge expérimentale de la norme C23. La capacité de renforcer la sûreté des programmes compilés avec le compilateur Clang a été aussi améliorée pour se rapprocher de ce qui est possible de faire avec le compilateur GCC. De nombreuses fonctions mathématiques ont une version vectorisée pour l’architecture Aarch64 ce qui peut améliorer les performances pour cette architecture.

Pour finir le débogueur améliore significativement son API Python pour faciliter sa manipulation à travers un programme ou script écrit dans ce langage. La prise en charge du protocole Debugger Adapter Protocol s’améliore encore pour faciliter sa manipulation par divers IDE qui s’en servent pour l’intégrer. Les informations de débogage du programme cible au format DWARF sont lues dans un fil d’exécution dédié pour améliorer le temps de chargement.

Mise à niveau de la suite de compilateurs LLVM vers la version 19. Les paquets versionnés des versions précédentes sont toujours disponibles pour ceux qui ont besoin de la compatibilité avec les anciennes bibliothèques. Les paquets clang, compiler-rt, lld et libomp sont maintenant générés à partir du fichier de spécification du paquet llvm ce qui n’était pas le cas avant. Cela permet entre autres de simplifier leur maintenance mais aussi d’appliquer une optimisation Profile-Guided Optimizations sur ces binaires pour améliorer les performances. Les paquets Fedora compilés avec Clang bénéficient aussi de la compilation avec l’option -ffat-lto pour avoir des bibliothèques ayant le bitcode LTO en plus du binaire au format ELF, ce qui permet de réduire le temps de l’édition de lien quand ces bibliothèques sont impliquées. Le tout sans recourir à des macros pour obtenir le résultat après la compilation des paquets et sans renoncer à la compatibilité pour les logiciels non compilés avec ce mode activé.

Retrait de Python 2.7 dans les dépôts, seule la branche 3 est maintenue dorénavant. Enfin, cela est vrai pour l’implémentation de référence, il reste possible de le faire via PyPy qui fourni toujours un support de la version 2.7 via le paquet pypy. Pour rappel, Python 2.7 n’est plus maintenu depuis début 2020, mais ce maintien était nécessaire pour certains paquets qui n’avaient toujours pas terminé leur portage, en particulier le logiciel GIMP, cas abordé plus haut. Les autres paquets concernés n’étaient plus vraiment maintenus de fait et ont été retirés. Cela devenait nécessaire car avec la fin de support de RHEL 7 prochainement, plus aucun correctif pour Python 2 ne sera développé à l’avenir rendant la situation plus critique encore.

D’ailleurs Python bénéficie de la version 3.13. Cette version fournit un nouvel interpréteur interactif avec la coloration activée par défaut pour le prompt ou les erreurs. Il donne la possibilité d’avoir de l’édition multi-lignes qui est préservée dans l’historique. Les touches F1, F2 et F3 donnent respectivement l’accès à une aide interactive, à la navigation de l’historique de l’édition et à un mode de copie plus simple pour copier-coller de gros blocs de code. Les messages d’erreur sont également plus clairs.

En dehors de cela, Python dispose du tant attendu mode sans verrou global nommé GIL ce qui permet d’améliorer les performances et de faire de réels fils d’exécution parallèle dans un programme. Mais ce mode étant expérimental, il faut installer le paquet python3.13-freethreading et exécuter Python avec la commande python3.13t pour en profiter.

Le compilateur juste à temps n’est quant à lui pas fourni d’une façon ou d’une autre, cette fonctionnalité étant aussi expérimentale.

Python est aussi compilé avec l’optimisation -O3 activée, en ligne avec la manière de faire par le projet officiel et améliorant les performances. Selon le test pyperformance le gain de performance est en moyenne 1,04 fois plus rapide rien qu’avec cette option. Auparavant Python était compilé avec l’optimisation -O2 qui est moins agressive, cependant la nouvelle option augmente la taille des binaires concernés d’environ 1.2% (soit 489 kio).

Le framework d’écriture de tests en Python, Pytest se teste avec sa version 8. Cette version n’est pas compatible avec la version précédente, de nombreux éléments obsolètes sont maintenant traités comme des erreurs, et de même la façon dont les tests sont récupérés dans l’arborescence d’un code source a été modifiée ce qui peut poser différents problèmes.

En termes d’amélioration, il propose un meilleur affichage des diff en cas d’erreur lors de l’exécution d’un test, le rendant plus lisible et plus proche du visuel d’un différentiel généré à partir de la commande diff.

Mise à jour du langage Go vers la version 1.23. Cette version apporte la télémétrie pour collecter des données sur l’usage de la chaine de compilation Go aux développeurs du projet, par défaut dans Fedora la télémétrie est activée mais reste uniquement sur votre machine, rien n’est envoyé aux serveurs du projet. Ce comportement peut être changé dans les options.

Autrement, quand le temps de compilation est amélioré lorsqu’un profil d’optimisation est utilisé, passant d’un délai supplémentaire pouvant aller jusqu’au double du temps de compilation normal à maximum 10% supplémentaire maintenant. Les applications Go ont un usage de la pile qui est légèrement réduit tandis que pour l’architecture x86_64, au détriment d’une légère augmentation de la taille du binaire, les boucles peuvent avoir une amélioration de performances d’environ 1-1,5%.

Mise à jour dans l’écosystème Haskell GHC 9.6 et Stackage LTS 22. Le compilateur en lui-même propose de compiler le code pour être exécuté en tant que programme WebAssembly ou JavaScript. Les deux sont cependant considérés comme en développement et peuvent être sujets à des bogues. L’ensemble des messages d’erreur ont maintenant un code unique, permettant de simplifier la recherche d’une explication et d’une solution concernant celui-ci.

Le langage Perl passe à la version 5.40. Un nouveau mot clé __CLASS__ donne la classe d’exécution réelle dont l’instance d’objet est membre, ce qui est utile pour les constructeurs de classes enfants, car l’accès à $self n’étant pas autorisé dans ce contexte. Un autre mot clé :reader est proposé, ajouté à un membre de classe il permet de définir automatiquement une fonction du même nom que le membre, qui renvoie cette valeur. Un nouvel opérateur ^^ est disponible, étant l’équivalent de && et || mais pour la fonction logique ou exclusif.

Node.js 22 devient la version de référence, tandis que la version 20 et 18 restent disponibles en parallèle. Cette version propose entre autres un client Websocket natif sans dépendances additionnelles, une mise à jour habituelle du moteur JavaScript V8 vers la version 12.4 qui propose notamment un ramasse-miette WebAssembly. Les flux de données passent par défaut d’un buffer de 16 kib à 64 kib ce qui augmente les performances au détriment de la consommation de mémoire vive. Enfin le compilateur JIT Maglev fourni par le moteur V8 est activé par défaut, qui améliore les performances en particulier pour les petits programmes exécutés en ligne de commande.

Pour des raisons de changement de licence, le gestionnaire de bases de données clé-valeur Redis est remplacé par Valkey. En effet Redis a adopté la licence RASLv2/SSPL en remplacement de la licence BSD qui n’est pas une licence libre ce qui est en conflit avec les règles de Fedora concernant les licences des logiciels proposés dans ses dépôts. Valkey est un fork de Redis qui réutilise la même licence originelle. À ce jour pas d’incompatibilité est à prévoir pour les utilisateurs de ce logiciel, mais un paquet valkey-compat est proposé pour migrer la configuration et les données depuis Redis. Le changement est effectué automatiquement lors de la mise à niveau de Fedora pour ces utilisateurs.

La bibliothèque Python d’apprentissage profond Pytorch est éclairée avec sa version 2.4. Le changement majeur de cette version est la prise en charge de ROCm pour tirer parti de l’accélération matérielle de l’intelligence artificielle proposée par AMD. Il y a également une amélioration de performances pour ceux utilisant GenAI sur un CPU ou encore exécutant sur des processeurs AWS Graviton3 à base d’architecture Aarch64.

L’API engine de la bibliothèque OpenSSL est dépréciée car non maintenue tout en gardant une ABI stable. En effet cette API n’est pas conforme aux standards FIPS et n’est plus maintenue depuis la version 3.0 d’OpenSSL. Aucun nouveau paquet ne peut dépendre de celui-ci jusqu’à sa suppression définitive pour simplifier la transition. Le code lié à cette API est fourni par le paquet indépendant openssl-engine-devel pour ceux qui en ont besoin. L’objectif à terme est de simplifier la maintenance tout en réduisant la surface d’attaque.

Projet Fedora

L’édition de Fedora KDE pour l’architecture AArch64 est maintenant bloquante pour les sorties d’une nouvelle version. L’édition doit être suffisamment stable pour qu’une nouvelle version de Fedora Linux voit le jour. Cela était déjà le cas pour Fedora Workstation de cette architecture et pour Fedora KDE pour l’architecture x86_64. L’objectif est de garantir une certaine fiabilité pour ses utilisateurs.

Phase 4 de l’usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora. Cela devait être l’ultime phase mais quelques contretemps repoussent à nouveau l’échéance. Cette étape et la suivante sont en fait la conversion massive des paquets vers le nouveau format, comme rapporté par ce document, la progression reste rapide et près de 98,5% des licences mentionnées dans les paquets sont déjà converties.

Les bibliothèques Java n’ont plus une dépendance explicite envers le runtime de Java pour simplifier la maintenance, rien ne change concernant les applications. L’objectif est d’éviter de spécifier une version spécifique de la version de Java pour du code qui finalement n’est pas exécuté directement, la dépendance revenant plutôt aux applications à ce sujet. Cela peut faciliter les utilisateurs ou mainteneurs d’utiliser différents JDK pour ces bibliothèques. Cela simplifie considérablement aussi la maintenance des paquets Java dans Fedora, car il n’est plus nécessaire de mettre à jour la valeur de la version du JRE requis.

Le paquet systemtap-sdt-devel n’a plus l’outil dtrace qui a été mis dans le paquet systemtap-sdt-dtrace. L’objectif est de supprimer la dépendance Python dans ce paquet qui est utilisé pour l’image de compilation des paquets de Fedora. Plusieurs centaines de paquets peuvent ainsi être générés plus rapidement par cette dépendance en moins.

Ajout d’une tâche de nettoyage lors de la génération des paquets RPM pour améliorer la reproductibilité des paquets. Depuis quelques années Fedora fait un effort pour rendre la conception de ses paquets reproductibles. L’objectif est qu’un utilisateur devrait être en mesure de recompiler un paquet de son côté avec le fichier spec RPM + sources additionnelles de Fedora et obtenir exactement le même paquet, au bit près, garantissant que le paquet a été généré avec ces éléments sans altérations malveillantes. Cela peut également faciliter le développement, car il rend la comparaison entre versions d’un paquet plus facile à analyser car seuls les changements dans le code sont différents et non des éléments annexes.

Un effort a été fait récemment qui repose notamment sur l’usage du programme add-determinism pour retirer du code source des éléments non déterministes comme la date de compilation. Ce programme est appelé à la fin de la génération du paquet. Fedora n’a pas réutilisé le travail de Debian à base du script strip-nondeterminism qui est un script Perl qui ajouterait une dépendance relativement lourde pour générer tous les paquets de Fedora.

Mise à jour de createrepo_c à la version 1.0 qui gère la génération des métadonnées des dépôts de Fedora. Les versions stables et Rawhide de Fedora vont partager maintenant la même configuration des métadonnées, ce qui rendra la maintenance côté infrastructure plus simple et cohérente. Toutes les métadonnées sont compressées, avant seulement les métadonnées primaires l’étaient pour les versions stables de Fedora par exemple. Certaines données ou métadonnées étaient compressées suivant différents algorithmes :

• gzip pour les métadonnées des dépôts ;
• XZ pour les données XML concernant les mises à jour dans les dépôts concernés.

Maintenant tout cela utilise l’algorithme zstd ce qui devrait améliorer un peu la bande passante et la consommation d’espace de stockage. Il n’est pas exclu de basculer à l’avenir sur zlib-ng dans ce but.

Les fichiers sqlite renseignant la composition des dépôts n’étaient utiles que pour le gestionnaire de paquets YUM, avec son remplacement par DNF depuis quelques années il est inutile de les générer ce qui avait un coût en espace de stockage.

La communauté francophone

L’association

Borsalinux-fr est l’association qui gère la promotion de Fedora dans l’espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l’association.

Nous lançons donc un appel à nous rejoindre afin de nous aider.

L’association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l’ensemble des évènements majeurs concernant le libre à travers la France principalement.

Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

• adhérer à l’association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
• participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l’association sur différents évènements francophones ;
• concevoir des goodies ;
• organiser des évènements type Rencontres Fedora dans votre ville.

Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.

Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuelles chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l’avons mis en place en visioconférence sur Jitsi.

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.

Le moins que l’on puisse dire, c’est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège et les autres contributeurs et relecteurs pour leurs contributions.

La synchronisation du travail se passe sur le forum.

Si vous avez des idées d’articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n’hésitez pas à participer.

Comment se procurer Fedora Linux 41 ?

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

Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.

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

De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 41.

En ce mardi 17 septembre, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 41.

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 41 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 22 octobre ou 5 novembre.

Sommaire

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

Expérience utilisateur

• Passage à GNOME 47 ;
• L'environnement de bureau léger LXQt passe à la version 2.0 ;
• L'éditeur d'image GIMP utilise la branche de développement qui deviendra la version 3 ;
• Le gestionnaire de listes de tâches Taskwarrior évolue à la version 3 ;
• La mise à jour du cœur des systèmes atomiques de bureau peut se faire sans droits administrateurs, mais pas les mises à niveau de celui-ci à savoir passer d'une version Fedora Linux Silverblue 40 à Fedora Linux Silverblue 41 ;
• Mise à disposition des images Spin KDE Plasma Mobile et Fedora Kinoite Mobile ;
• De même le gestionnaire de fenêtres Miracle exploitant Wayland est proposé dans Fedora et bénéficie de son propre Spin ;
• L'installation de Fedora Workstation se fera avec le protocole d'affichage Wayland uniquement, X11 reste disponible et installable après.

Gestion du matériel

• L'installation du pilote propriétaire de Nvidia via GNOME Logiciels est compatible avec les systèmes utilisant l'option Secure Boot ;
• Prise en charge des caméras MIPI pour les systèmes utilisant Intel IPU6 qui concerne de nombreux ordinateurs portables actuels ;
• L'installateur Anaconda prend en charge le chiffrement matériel des disques via le standard TCG OPAL2, mais cela nécessite de passer via un fichier kickstart pour personnaliser l'installation ;
• Utilisation par défaut de l'outil tuned au lieu de power-profiles-daemon pour la gestion de l'énergie de la machine ;
• Mise à jour de ROCm 6.2 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d'AMD ;
• L'outil de débogue des tables ACPI nommé acpica-tools ne prend plus en charge les architectures gros boutistes tels que s390x ;
• PHP ne prend plus en charge les processeurs x86 32 bits.

Internationalisation

• Le gestionnaire d'entrées IBus par défaut pour la langue traditionnelle chinoise de Taiwan passe de ibus-libzhuyin à ibus-chewing.

Administration système

• Le gestionnaire de paquet dnf est mis à jour vers sa 5e version ;
• Tandis que la commande rpm utilise la version 4.20 ;
• Les systèmes Fedora atomiques de bureau et Fedora IoT disposent de bootupd pour la mise à jour du chargeur de démarrage ;
• Les images atomiques de Fedora proposent les outils dnf et bootc, ce premier est utilisable dans un contexte de développement pour l'instant mais le second peut commencer à servir à déployer des images du système qui sont bootables ;
• La bibliothèque de sécurité OpenSSL n'accepte plus les signatures cryptographiques avec l'algorithme SHA-1 ;
• Stabilisation de la fonctionnalité de Fedora Linux 36 où ostree prenait en charge les formats OCI/Docker pour le transport et le mécanisme de déploiement des conteneurs ;
• Le gestionnaire de réseaux NetworkManager ne prend plus en charge la configuration dans le format ifcfg qui était déjà désuet depuis des années ;
• Dans la même veine, le paquet network-scripts a été retiré, mettant fin à la gestion du réseau via les scripts ifup et ifdown ;
• Les interfaces réseaux pour les éditions Cloud vont utiliser les nouveaux noms par défaut comme adoptés par les autres éditions il y a des années au lieu de conserver les noms traditionnels tels que eth0 ;
• Le gestionnaire de virtualisation libvirt utilise maintenant par défaut le pare-feu nftables au lieu de iptables pour son interface réseau vibr0 ;
• L'outil Netavark pour gérer la pile réseau des conteneurs, notamment avec podman, utilise également par défaut le pare-feu nftables au lieu de iptables ;
• Les unités système de systemd vont utiliser par défaut beaucoup d'options pour améliorer la sécurité des services ;
• Introduction de l'outil fedora-repoquery pour faire des requêtes sur les dépôts comme savoir la version exacte d'un paquet spécifique dans une autre version de Fedora, la date de mise à jour d'un dépôt, ou connaître les paquets qui dépendent d'un paquet spécifique (dépendance inverse donc), etc. ;
• Le gestionnaire de conteneurs Kubernetes a des nouveaux paquets versionnés, permettant d'avoir plusieurs versions en parallèle. Ici les versions 1.29, 1.30 et 1.31 sont proposées avec des noms comme kubernetes1.31 ;
• L'implémentation des interfaces de Kubernetes fait par l'OCI a ses propres paquets cri-o et cri-tools qui sont également versionnés pour pouvoir suivre les versions de Kubernetes.

Développement

• Mise à jour de la suite de compilation GNU : binutils 2.42, glibc 2.40 et gdb 15 ;
• Mise à niveau de la suite de compilateurs LLVM vers la version 19 ;
• Retrait de Python 2.7 dans les dépôts, seule la branche 3 est maintenue dorénavant ;
• D'ailleurs Python bénéficie de la version 3.13 ;
• Python est aussi compilé avec l'optimisation -O3 activée, en ligne avec la manière de faire par le projet officiel et améliorant les performances ;
• Le framework d'écriture de tests en Python, Pytest se teste avec sa version 8 ;
• Mise à jour du langage Go vers la version 1.23 ;
• Mise à jour dans l'écosystème Haskell GHC 9.6 et Stackage LTS 22 ;
• Le langage Perl passe à la version 5.40 ;
• Node.js 22 devient la version de référence, tandis que la version 20 et 18 restent disponibles en parallèle ;
• Pour des raisons de changement de licence, le gestionnaire de bases de données clé-valeur Redis est remplacé par Valkey ;
• La bibliothèque Python d'apprentissage profond Pytorch est éclairée avec sa version 2.4 ;
• L'API engine de la bibliothèque OpenSSL est désactivée car non maintenue tout en gardant une ABI stable.

Projet Fedora

• L'édition de Fedora KDE pour l'architecture AArch64 est maintenant bloquante pour les sorties d'une nouvelle version. L'édition doit être suffisamment stable pour qu'une nouvelle version de Fedora Linux voit le jour ;
• Ultime phase 4 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora ;
• Les bibliothèques Java n'ont plus une dépendance explicite envers le runtime de Java pour simplifier la maintenance, rien ne change concernant les applications ;
• Le paquet systemtap-sdt-devel n'a plus l'outil dtrace qui a été mis dans le paquet systemtap-sdt-dtrace ;
• Ajout d'une tâche de nettoyage lors de la génération des paquets RPM pour améliorer la reproductibilité des paquets ;
• Changement dans les métadonnées des dépôts de Fedora, avec l'usage de l'algorithme de compression zstd et l'abandon des bases de données sqlite pour diminuer la taille des données à télécharger ou à stocker.

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 40 ou 39 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 41.

Bons tests à tous !

En ce mardi 23 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 40.

Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Cette 40e édition propose principalement une mise à jour de son interface principale GNOME 46 et de son concurrent KDE Plasma 6 qui passe à Wayland par défaut au passage.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• La communauté francophone
  • L'association
  • La documentation
• Comment se procurer Fedora Linux 40 ?

Expérience utilisateur

Passage à GNOME 46. Cette version se démarque par beaucoup d'améliorations pour son navigateur de fichiers nommé Fichiers. Il dispose dorénavant, en plus d'une recherche dans le dossier et sous-dossiers en cours, d'une recherche globale utilisable via le bouton dédié avec une icône de loupe ou par le raccourci clavier Ctrl+Shift+F (contrairement à la recherche locale qui se fait via le raccourci Ctrl+F). Il permet de chercher dans l'ensemble du répertoire utilisateur voire davantage selon les préférences de l'utilisateur.

L'icône de loupe prend place où était l'icône de progression lors des opérations sur les fichiers comme les décompressions ou la copie de fichiers. De fait ces opérations sont affichées en bas de la barre latérale ce qui permet d'afficher plus d'informations en un coup d’œil. L'application bénéficie en outre d'améliorations de performances en particulier pour afficher de gros dossiers avec des images ou lors du passage d'une vue liste à une vue par icônes et vice-versa. Plus de périphériques sur le réseau peuvent être découverts automatiquement permettant notamment de parcourir leurs fichiers.

GNOME prend en charge les comptes Microsoft OneDrive ce qui permet de facilement parcourir les fichiers sauvegardés avec ce service. Dans les comptes à distance, le protocole WebDAV est aussi pris en charge pour l'accès à des calendriers, listes de contacts et autres fichiers partagés. Pour l'authentification de ces comptes en ligne, le navigateur par défaut est utilisé dorénavant ce qui permet d'utiliser une plus grande diversité de moyens d'authentifications comme l'usage de périphériques USB dédiés.

Pour les amateurs de la connexion distante, il est maintenant possible de se connecter à GNOME graphiquement à distance via le protocole RDP. Auparavant seulement une session ouverte pouvait être pilotée ainsi. Cette option est désactivée par défaut et nécessite des droits appropriés, tout se configure via le panneau de configuration tout comme le bureau distant.

En parlant du panneau de configuration, ce dernier a été amélioré en regroupant plusieurs configurations par sections afin d'améliorer la clarté de l'application. La liste des menus devenait particulièrement importante et rendait difficile la localisation des éléments à configurer. De plus, la configuration du pavé tactile a été améliorée pour permettre de choisir entre le clic dans un coin ou le clic à deux doigts pour réaliser l'équivalent d'un clic droit avec ce périphérique.

Côté accessibilité, le lecteur d'écran Orca a été modernisé pour le rendre plus performant, plus fiable et plus compatible avec les applications Wayland ou celles exécutées dans un bac à sable tel que Flatpak. Il est possible de couper temporairement Orca avec le raccourci clavier Ctrl+Alt+Shift+Q ce qui est particulièrement utile en cas de conflit entre deux lecteurs d'écran ou si une application utilise du son aussi.

Les notifications dans GNOME indiquent par quelle application elles ont été émises. Il est maintenant possible d'étendre facilement la notification afin de pouvoir la visualiser en entier, utilisant une vue plus compacte par défaut.

De manière plus générale, GNOME bénéfice d'améliorations de performances notamment pour son terminal, son moniteur système qui bénéficie aussi d'un graphe dédié aux entrées / sorties sur les espaces de stockage, pour l'enregistrement de l'écran, le visionneur d'images ou encore pour la recherche globale de GNOME. L'ensemble des applications GTK4 bénéficie d'un nouveau moteur de rendu qui améliore le rendu du texte mais aussi les performances.

L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6. Au passage Plasma 6 utilise Wayland par défaut, et s'il était prévu de supprimer totalement la possibilité de l'utiliser avec X11 pour simplifier la maintenance, des volontaires ont permis de repousser l'échéance pour l'instant.

Sous le capot, cette version utilise la nouvelle bibliothèque majeure graphique qu'elle emploie à savoir Qt 6. C'était l'occasion par ailleurs de rationaliser les différentes couches techniques et APIs internes afin de supprimer ce qui n'était plus au goût du jour ou trop peu employé pour être maintenu.

Cette version propose la prise en charge partielle du rendu des couleurs en HDR pour les applications et matériel compatibles, mais aussi un profil de couleur spécifique par écran afin d'avoir un rendu fidèle des couleurs. Dans cette thématique pour les personnes souffrant de daltonisme ou d'autres formes de maladies dichromatiques peuvent utiliser des filtres pour améliorer la lisibilité des applications et de leur contenu.

Dans les changements plus classiques, la barre principale est par défaut en mode flottant comme pour beaucoup de docks d'autres environnement de bureaux ou systèmes d'exploitation. Il est bien sûr possible de changer tout cela dans les paramètres et plus encore concernant cette barre principale. Concernant l'affichage principal, l'effet cube en cas de changement de bureau virtuel est de nouveau disponible. Pour la capture d'écran, il est possible de choisir une zone arbitraire de l'écran, d'utiliser le codec VP9 pour les enregistrements vidéos et de choisir sa qualité.

Le thème par défaut de l'environnement nommé Breeze bénéficie d'un rafraichissement, il utilise moins de cadres et a un affichage un peu plus compact.

Comme pour GNOME, la recherche a bénéficié d'un effort important. En plus de permettre la conversion de fuseaux horaires ou de trier les résultats par type, les performances sont grandement améliorées : jusqu'à 200% plus rapide pour chercher des documents, jusqu'à 60% plus rapide pour trouver une application, le tout jusqu'à moins 30% d'usage du processeur. La recherche obtient les résultats pour les textes traduits dans votre langue ou en anglais pour les noms ou les descriptions d'applications par exemple.

Il est dorénavant possible de s'authentifier par mot de passe ou par empreinte digitale en même temps, il n'est plus nécessaire de forcer l'une des deux options.

Et tant d'autres changements encore.

Gestion du matériel

Fourniture de ROCm 6 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d'AMD. Il concerne notamment les puces AMD Instinct MI300A et MI300X, et fournit de nouveaux algorithmes optimisés du mécanisme d'attention et de bibliothèques de communication. Il permet l'usage de flottant 8 bits pour gagner en consommation mémoire au détriment de la précision du modèle pour PyTorch et hipblasLT. Via la plateforme AMD Infinity Hub, il est possible d'obtenir des paquets prêts à l'usage pour certains travaux en IA ou calculs haute performance notamment pour les calculs scientifiques.

Passage à l'étape 2 de la prise en charge du noyau unifié nommée UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet. L'objectif dans cette phase est de pouvoir démarrer sur de tels noyaux directement sans chargeur de démarrage intermédiaire, tout en offrant la possibilité de démarrer sur d'autres noyaux et de passer automatiquement au noyau suivant par défaut suite à une mise à jour. Les machines Aarch64 (ARM 64 bits) peuvent également s'en servir maintenant. Une image pour cette architecture et x86_64 doit également être fournie pour un contexte de virtualisation en étant basée sur ces fichiers kickstart.

Si vous souhaitez tester cela sur un système existant, vous pouvez installer les paquets virt-firmware, uki-direct avant d'exécuter le script sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh pour configurer les partitions proprement afin d'être découvrables par le système, puis enfin installer le paquet kernel-uki-virt pour qu'il installe le noyau proprement avec la nouvelle méthode. Il est préférable de tester cela sur une machine virtuelle ou si vous savez ce que vous faites avec du matériel standard type ahci / nvme pour le stockage principal. Bien sûr ce travail reste expérimental et est réservé à ceux qui savent comment faire pour réparer le système en cas de problèmes.

Internationalisation

Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30. Les commandes pour lancer et relancer IBus fonctionnent depuis l'environnement Plasma Wayland dorénavant, et pour cet environnement aussi les préférences sont maintenant accessibles depuis le menu non contextuel.

Mise à jour de ibus-anthy 1.5.16 pour la saisie du japonais. Le principal changement est la conversion possible d'ère japonaise avec 2024.

Administration système

NetworkManager tente de détecter par défaut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection (RFC 5227) avant de l'attribuer à la machine. En somme au moment de s'attribuer une adresse IP donnée, une requête ARP est envoyée au réseau concernant cette adresse. Si une réponse est obtenue, l'adresse est déjà utilisée et n'est donc pas exploitable sans perturber le réseau. Ce mécanisme existe pour les réseaux avec IP fixes ou même avec un serveur DHCP central car rien n'empêche la présence d'une machine configurée avec une IP fixe dans le réseau malgré tout. Si le réseau a un serveur DHCP et qu'un conflit est détecté, la réponse DHCPDECLINE sera envoyée pour obtenir peut être une autre adresse. En cas de conflit une erreur sera rapportée permettant à l'utilisateur de diagnostiquer le problème et d'y apporter une solution. Par défaut le système attendra 200 ms avant de décider qu'il n'y a aucune réponse. Pour l'IPv6 cela est inclus dans le standard RFC 4862 ce qui rend ce changement non nécessaire dans ce cas de figure.

NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. En effet, certains systèmes utilisent l'adresse Mac pour identifier les machines en déplacement de réseau en réseau permettant une pseudo géolocalisation ce qui nuit à la vie privée. Mais la méthode usuelle de changer d'adresse MAC aléatoirement à chaque connexion pose un problème en cas de réseau restreignant l'accès à certaines adresses MAC uniquement ou en changeant d'adresse IP à chaque reconnexion. Cette méthode est un compromis entre le respect de la vie privée et le confort d'utilisation. Cela est fait en ajoutant la configuration wifi.cloned-mac-address="stable-ssid" dans le nouveau fichier /usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.conf.

Les entrées des politiques SELinux qui font référence au répertoire /var/run font maintenant référence au répertoire /run. Il y a dix ans déjà que le premier répertoire a bougé vers le deuxième chemin mais SELinux a gardé les vieilles règles en utilisant un lien d'équivalence entre eux pour permettre leur utilisation. Cependant certains outils comme restorecon ne gèrent pas bien cette situation tout comme les administrateurs systèmes qui ne sont pas sûrs de comment écrire proprement de nouvelles règles. Pour résoudre le problème le lien d'équivalence passe de /run = /var/run à /var/run = /run.

L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux. Il pouvait exploiter les fichiers /etc/passwd et /etc/group via l'utilisation de l'option id_provider=files. Cependant cette option n'est plus proposée par le projet officiel et n'était à l'époque conservée que pour permettre l'authentification via des cartes à puce ou l'enregistrement de sessions. Mais dans les deux cas il est possible de passer à la méthode proxy via l'option id_provider=proxy pour le remplacer dans ces cas d'usage. Un guide officiel est proposé pour effectuer la conversion pour ceux qui en ont besoin.

DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets. Jusqu'à présent il le faisait par défaut parmi d'autres métadonnées, mais cette information n'est en réalité nécessaire que dans certains cas précis qui ne concernent pas celui de la majorité des utilisateurs. Notamment pour quelques paquets ayant une dépendance envers un fichier particulier plutôt qu'un paquet donné ou si on cherche un paquet fournissant un fichier spécifique. Cela permet de réduire les ressources consommées chez les utilisateurs mais aussi au sein de l'infrastructure de Fedora car il n'est plus nécessaire de fournir ces données assez conséquentes de manière systématique.

L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares. Ce fichier qui représente environ 1 Mio est téléchargé quotidiennement parfois sur des liaisons coûteuses. Ainsi la pression est réduite sur les infrastructures notamment le CDN fwupd et la bande passante en utilisant localement la ressource quand elle est disponible. Passim utilise avahi pour signaler son service sur le réseau local qui est disponible via le port 27500 afin que les autres clients puissent identifier si des métadonnées sont disponibles localement.

Les systèmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise à jour du chargeur de démarrage. Par conception les systèmes avec rpm-ostree comme ceux-ci n'ont pas le chargeur de démarrage qui se met à jour par ce biais car cela n'est pas une opération sûre. En effet, la mise à jour de ces systèmes repose sur le principe de transaction pour que le passage d'un état à un autre soit fiable, cependant ce mécanisme ne fonctionne pas bien pour le chargeur de démarrage qui est un composant distinct et critique. On retrouve la même problématique pour les systèmes utilisant un mécanisme de mise à jour basé sur une partition A et B et passant de l'un à l'autre. D'où la création de cet utilitaire qui est mis à disposition pour ceux qui le souhaitent, du moins pour les machines disposant d'un EFI. La mise à jour est pour le moment manuelle à la demande avec la commande bootupctl update. La mise à jour automatique sera prévue dans le futur.

Le paquet libuser est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimé. La bibliothèque libuser sert à cacher les différences entre les utilisateurs locaux et distants via le protocole LDAP. Mais la prise en charge de ce protocole reste incomplet et il n'y a pas de plan pour aller plus loin, comme sssd peut la remplacer dans ce rôle, la décision de la supprimer prochainement de Fedora fait sens. Pour l'instant seuls les paquets usermode et util-linux en ont encore besoin. Le paquet passwd quant à lui disparaît pour se débarrasser de la dépendance à libuser. La commande pour changer de mot de passe ne change pas, mais est fournie par le paquet shadow-utils.

Le paquet cyrus-sasl-ntlm a été supprimé. Le protocole d'identification NTLM n'est plus maintenu, au profit du protocole Kerberos et ce composant dans SASL n'est plus maintenu depuis des années justifiant une telle décision.

La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM. BerkeleyDB 5.x fourni par Fedora n'est plus à jour ce qui pose des soucis en terme de bogues et de sécurité, d'autant plus avec le rôle de PAM dans le système. La licence de BerkeleyDB a changé dans la branche 6.x, passant de BSD à AGPL rendant impossible l'adoption de cette version plus à jour pour ce composant, les licences n'étant pas compatibles. Ainsi GDBM se pose comme une alternative pour résoudre ce problème. BerkeleyDB 5.x a débuté sa sortie du projet Fedora depuis Fedora 33, ceci est une étape de plus dans cette direction.

Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne. La raison est analogue au paragraphe précédent.

Le serveur LDAP 389 passe de la version 2.4.4 à la version 3.0.0. Le projet abandonne la prise en charge de BerkeleyDB pour sa base de données interne pour la même raison que précédemment. En dehors de cela qui introduit des incompatibilités, cette mise à jour est en réalité assez mineure sur les autres aspects en fournissant essentiellement des correctifs de bogues.

Le paquet iotop est remplacé par iotop-c. Si le nom du paquet change, celui du binaire installé ne change pas. iotop n'est plus vraiment maintenu depuis une dizaine d'années et est sévèrement concurrencé par iotop-c sur cet aspect qui bénéfice en plus d'une empreinte mémoire plus petite étant rédigé en C au lieu de Python. Il n'est pas pertinent aux yeux des mainteneurs de maintenir les deux ainsi.

L'orchestrateur de conteneurs Kubernetes évolue de la version 1.27 à la version 1.29. Ce changement est communiqué car Kubernetes déconseille le saut des versions ce que Fedora fait actuellement en passant à la version 1.28 en fournissant ainsi la dernière version disponible. Cette version propose aux utilisateurs la possibilité d'avoir un écart de version de n-2 à n-3 pour les versions mineures entre le nœud principal et le plan de contrôle. Il est également possible si un nœud est indisponible suite à une panne ou à un état non récupérable de démarrer les services qu'il gérait dans un autre nœud dans un état sain. Le mode d'accès aux données ReadWriteOncePod devient accessible sans restrictions, permettant de restreindre l'accès à des données à un seul pod à la fois plutôt qu'à un seul nœud, pour réduire le risque d'accès concurrents en particulier en écriture. De même le module KMS v2 est disponible à tous pour réaliser les services de chiffrement pour vos APIs.

Par ailleurs les paquets de Kubernetes sont restructurés. L'objectif est de se rapprocher de l'organisation du projet upstream et de simplifier la vie des utilisateurs. Ainsi le paquet kubernetes récupère l'utilitaire kubelet qui avait son paquet dédié et les services fournis via l'ancien sous-paquet kubernetes-master sont renommés kubernetes-systemd. Les paquets kubernetes-client et kubernetes-kubeadm restent inchangés.

Pendant que podman est mis à jour vers la version 5. Cette version abandonne la prise en charge des cgroupv1 du noyau, de même que les plugins CNI ou la base de données clé / valeur Boltdb au profit de SQLite pour les nouvelles instances. Le format des fichiers de configuration pour les podman machines a été profondément remanié, rendant nécessaire la recréation des machines virtuelles concernées conçues avant cette version.

Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version. Cette version propose du code multithreadé et qui télécharge plus vite grâce à la prise en charge du protocole HTTP2 avec la compression ou le téléchargement parallèle. Il propose plus d'options, il a également plus de tests automatiques pour s'assurer de sa robustesse dans le temps. Sa réécriture dans un style plus moderne devrait faciliter l'adoption de nouveaux protocoles à l'avenir. Par contre les protocoles dépassés WARC et FTP sont moins bien pris en charge. La licence change pour GPLv3+, de même que sa bibliothèque libwget2 vers LGPLv3+.

Le gestionnaire de base de données PostgreSQL migre vers sa 16e version. De part l'arrêt des modules, les paquets pour des versions alternatives sont également réintroduits. Ainsi les paquets postgresql15* font leur apparition pour la prise en charge de la version précédente, et les paquets postgresql17* seront proposés quand la 17e version sera disponible. En terme de changements apportés par cette nouvelle version, les jointures FULL ou OUTER sur des hash peuvent être parallélisées pour de meilleures performances. Il est dorénavant possible de répliquer des données depuis des serveurs dans un état standby, de même la réplication peut être appliquée en parallèle pour de larges transactions afin d'améliorer les performances de l'opération. La vue pg_stat_io fournit des informations statistiques concernant les entrées et sorties. SQL/JSON qui est introduit dans le standard SQL bénéficie de constructeurs dédiés pour créer des objets JSON mais aussi des fonctions identités pour connaître le type des clés. Et ce parmi de nombreuses corrections de bogues et d'amélioration de performances.

Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11 pour MariaDB. Le paquet community-mysql est renommé mysql tandis que le paquet mariadb ne fourni plus de binaires avec le nom mysql. En effet la décision à l'époque a été prise car il semblait convenu que MariaDB remplacerait MySQL tout comme LibreOffice a supplanté OpenOffice.org mais force est de constater que les deux projets vont cohabiter longtemps. Cela rend le tout plus simple pour l'utilisateur. Cependant, puisque ces logiciels évoluent séparément, ils deviennent peu à peu incompatibles et le mainteneur abandonne la possibilité d'utiliser MariaDB comme serveur avec MySQL comme client et vice-versa. Aucune autre distribution en fournissait une telle possibilité et cela devenait difficile à maintenir car cela était source de problèmes.

En terme de nouvelles fonctionnalités pour MariaDB, il est possible de lire entièrement les tables Information Schema Parameters et Information Schema Routines tout en améliorant les performances dans la procédure. Il est possible de savoir combien de temps une requête passe dans l'optimiseur via l'option ANALYZE FORMAT=JSON. Les semi-jointures pour la mise à jour ou la suppression de données sont optimisées. Les privilèges SUPER et READ ONLY ADMIN sont dorénavant distincts, à ce sujet il est possible de fournir à tous les utilisateurs des droits spécifiques via la requête GRANT <privilege> ON <database>.<object> TO PUBLIC.

Développement

Mise à jour de la suite de compilation GNU : GCC 14.0, binutils 2,41, glibc 2.39 et gdb 14.1.

Concernant la suite de compilateurs GCC, elle continue l'amélioration de la prise en charge des langages C23 et C++23, alors que débute la prise en charge de la future norme C++26. De nombreux modèles de puces Aarch64 et x86_64 bénéficient de micro-optimisations, tandis qu'il y a un début de prise en charge des nouvelles instructions pour l'architecture x86_64 d'Intel dénommées APX et AVX10. L'analyseur statique de code peut afficher visuellement les dépassements de tampons pour mieux comprendre ce qui se passe en mémoire.

Pour la suite d'outils binutils, cela se concentre surtout sur la prise en charge plus étendue des instructions des architectures Aarch64, RISC-V et x86_64.

Quant à la bibliothèque standard C glibc, cela se traduit par de nombreuses améliorations comme la prise en charge de la pile cachée pour éviter les attaques par modification d'adresse de retour, ce que Fedora Linux active par ailleurs. De même pour limiter certaines attaques, la glibc propose de pouvoir réécrire au lancement la PLT pour obtenir les adresses des fonctions des bibliothèques dynamiques plutôt que de les avoir lors du premier appel à chaque fonction. Le programme démarre plus lentement mais est plus sûr pour la suite. L'en-tête <stdbit.h> fait son apparition pour les manipulations sur les bits, opérations basées sur la norme de C20. Et une nouvelle fonction posix_spawnattr_setcgroup_np est ajoutée pour démarrer un processus dans un cgroup donné afin d'éviter des situations de concurrence entre le moment où le processus est démarré et où les restrictions s'appliquent.

Enfin le débogueur gdb propose un début de prise en charge du protocole de Microsoft Debugger Adapter Protocol pour faire le lien entre les débogueurs et des IDEs ou éditeurs de code afin de faciliter leur intégration mutuelle. Il peut également gérer des entiers au delà de 64 bits, de même que d'appeler une commande shell avec l'instruction $_shell pour obtenir son résultat. Les instructions de l'architecture Aarch64 SME et SME2 commencent à être gérées et l'API Python est considérablement étoffée pour ceux qui veulent scripter le débogueur.

La suite de compilateurs LLVM est mise à jour à la version 18. Fedora en profite pour que CLang utilise des informations de débogage au format DWARF-5 au lieu de DWARF-4 par défaut comme appliqué par le projet amont. Pour simplifier la procédure de compilation de Fedora pour les paquets utilisant cette chaîne de compilation, le Fat-LTO sera employé pour permettre l'usage du LTO quand c'est possible comme cela était déjà le cas avec GCC. Jusqu'alors ces paquets étaient compilés avec LTO par défaut avec une éventuelle conversion vers ELF à la main si la compatibilité le nécessitait ce qui était particulièrement lourd. Par ailleurs les paquets de compatibilité des versions précédentes fournissent les binaires des différents utilitaires et non plus seulement les bibliothèques et en-têtes.

Concernant les nouveautés apportées par le projet en lui même, comme pour la chaîne de compilation GNU, les architectures Aarch64, x86_64 ou RISC-V sont mieux gérées. Le compilateur CLang suit GCC avec du travail sur C++20, C++23 pour améliorer la compatibilité avec le standard et le début de prise en charge de la future norme C++26.

Mise à jour de la bibliothèque C++ Boost à la version 1.83. Depuis la version 1.81, cette bibliothèque propose un module pour communiquer avec les bases de données MySQL ou encore une bibliothèque Compat: pour fournir en code compatible C++11 des ajouts proposés par les standards ultérieurs.

Le langage Go passe à la version 1.22. La sémantique de la boucle for évolue un peu avec la création de la variable de boucle à chaque itération de boucle plutôt qu'à la première avec mise à jour à chaque passage. De plus il accepte l'usage des plages de valeurs basées sur des entiers. L'exécution des programmes gagne 1 à 3% grâce à l'optimisation de la localisation mémoire des métadonnées du ramasse miette. Les programmes compilés avec un profil d'optimisation peuvent gagner entre 2 et 14% de performances par rapport à la version précédente grâce à la possibilité d'appliquer la technique sur plus de fonctions qu'avant.

Le JDK de référence pour Java passe de la version 17 à 21. OpenJDK peut maintenant faire du filtrage par motif dans une instruction switch. Il est possible aussi d'affecter le résultat d'une identification de type dans une variable directement afin de pouvoir s'en servir immédiatement. Des fils d'exécution virtuels font leur apparition qui sont plus légers et performants, plutôt dédiés à des tâches courtes avec beaucoup d'attentes, ces tâches peuvent ainsi bénéficier de meilleure performance notamment en terme de latence. Il introduit également une API pour les collections d'objet en séquence (donc ordonnées). De même une nouvelle API pour manipuler les clés cryptographiques symétriques fait son entrée. Le ramasse miette Z Garbage Collector améliore ses performances.

Ruby 3.3 surveille sa syntaxe avec Prism. Prism est un gem introduisant un nouveau parseur très flexible qui a vocation à remplacer Ripper. Le compilateur juste à temps YJIT bénéficie de nombreuses améliorations comme de meilleures performances, une réduction de la consommation mémoire avec un code généré plus compact et avec moins de métadonnées et un temps de compilation plus court. Un concurrent RJIT fait son entrée, écrit en pur Ruby et non en C comme YJIT, il a plus vocation à servir de terrain d'expérimentation. Le ramasse miette est également plus performant.

Le langage PHP utilise la version 8.3. Cette version permet de définir des classes constantes, il propose également un attribut #[\Override] si une classe surcharge une méthode d'une classe parente. Une nouvelle fonction json_validate permet de vérifier la validité d'un JSON sans le décoder. Le Randomizer a plus de méthodes pour permettre de générer des noms ou nombres aléatoires suivant les besoins.

La boîte à outils pour le machine learning PyTorch fait son entrée dans Fedora. L'objectif est de fournir une meilleure expérience pour les développeurs de ce genre de solution. Un groupe de travail dédié s'est mis en place avec une réunion bi-hebdommadaire. Pour le moment l'architecture x86_64 est la seule prise en charge avec un effort important mis sur les solutions AMD.

Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité. Cette version apporte entre autre de l'annotation de type ce qui permet de construire des ORM sur un modèle déclaratif. Les opérations d'insertions sont aussi bien plus performantes quelque soit le gestionnaire de base de données derrière.

La bibliothèque de validation des données Pydantic utilise dorénavant la version 2. Outre l'amélioration des performances, il change radicalement son API ce qui coupe la compatibilité ascendante.

La bibliothèque Thread Building Blocks passe du fil 2020.3 au fil 2021.8. De même la compatibilité ascendante n'est pas garantie ce qui a rendu ce portage compliqué.

La bibliothèque OpenSSL 1.1 est supprimée ne laissant que la dernière version de la branche 3.x. Depuis Fedora 36 la branche 3 est employée par défaut dans Fedora. OpenSSL 1.1 n'est plus maintenue depuis fin de l'année dernière ce qui rend sa maintenance délicate et non sûre d'où son abandon malgré la faible compatibilité entre les deux versions pour ceux qui s'en servait encore.

Les bibliothèques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant. Ces versions sont plus rapides grâce à l'emploi des instructions plus modernes des processeurs actuels tout en gardant la compatibilité par rapport à l'implémentation de référence.

Le langage Python ne bénéficie plus de la version 3.7. Depuis juin de l'année dernière cette version n'est plus maintenue et il n'y a pas de raison de poursuivre son maintien dans les dépôts en tant que version de compatibilité.

Projet Fedora

L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji. L'utilitaire ImageFactory employé jusqu'à présent n'est plus maintenu. Les outils mkosi et osbuild ont été considérés mais non retenus, le premier car il manque de flexibilité pour fournir toutes les images souhaitées, tandis que le second est certes adopté par l'équipe de Fedora Workstation mais ne semble pas adapté aux besoins des images clouds qui reposent sur d'autres technologies dont rpm-ostree et doit fournir des délivrables plus variés également. En effet l'image cloud cible Vagrant, Azure, AWS, GCP et peut dorénavant viser aussi les images pour WSL2 ou pour conteneurs directement.

Tandis que l'édition Workstation aura son image ISO générée avec l'outil Image Builder. En effet ce dernier bien que déjà employé par Fedora Workstation bénéficie enfin de la prise en charge des images ISO live. Il remplace donc les outils lorax/livemedia-creator qui avaient beaucoup de problèmes. Il devient aussi plus simple pour quiconque de générer son image ISO avec un simple fichier TOML pour le décrire et quelques utilitaires en ligne de commande.

L'image minimale ARM sera construite avec l'outil OSBuild. Comme dans le cadre de l'édition Cloud, il remplace l'utilitaire ImageFactory qui montrait ses limites. L'objectif à terme est de pouvoir supprimer totalement ou partiellement les hacks nécessaires à ce jour pour utiliser cette image sur une grande variété de systèmes ARM.

Fedora IoT bénéficiera d'images pouvant démarrer dans des conteneurs. Ainsi il est possible de tester le système dans des conteneurs plutôt que via de la virtualisation classique ou sur des machines physiques. Cette flexibilité peut aider le test par les utilisateurs mais également par ses mainteneurs.

Il bénéficiera également des images Simplified Provisioning. Fedora IoT peut ainsi utiliser l'utilitaire coreos-installer pour l'installer sur le disque directement et ce en utilisant un argument noyau pour savoir sur quel disque l'installer. Ainsi pas besoin de fichier kickstart ou d’interaction avec l'utilisateur ce qui simplifie la procédure et son automatisation. Cela s'intègre parfaitement avec les dispositifs Fido Device Onboarding et Ignition pour la configuration de tels systèmes dans un environnement de production.

Et le tout sera construit en utilisant rpm-ostree unified core. L'ancien mode n'est en effet plus maintenu et moins testé. Le mode unifié permet au compose server, qui est l'image de base créée à partir de RPM, de fonctionner de manière similaire au client qui ajoute des commits par dessus pour personnaliser le contenu du système. Cela permet de simplifier la maintenance côté rpm-ostree mais aussi de résoudre certaines difficultés notamment pour la gestion du démarrage avec bootupd, les labels SELinux et l'utilisation de conteneurs pour les scriplets pré et post installations des paquets. Depuis Fedora Linux 39 où Silverblue et Kinoite ont amorcé la transition, l'édition IoT était la dernière variante à ne pas avoir franchi le pas.

Fedora sera construit avec DNF 5 en interne. Ainsi les outils Mock, Koji et Copr passent le cap, en attendant Fedora Linux 41 pour que cela soit le cas pour les utilisateurs de la distribution. L'objectif est ici double. Les développeurs de DNF auront un retour d'expérience grandeur nature sur cette version et permettra d'identifier d'éventuels problèmes. Pour l'infrastructure, DNF 5 est plus léger en mémoire, plus performant et consomme moins d'espace disque ce qui permettrait de gagner du temps dans la construction des RPM et des images et de réduire la pression sur le matériel employé à ces tâches.

Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros. Ces projets sont maintenant distincts upstream et ce premier dépend maintenant du second. L'objectif est de simplifier la possibilité d'exécuter des tests automatiques sur ces macros afin d'améliorer leur fiabilité.

Phase 3 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora. L'objectif de cette phase est de poursuivre le travail entamé dans les versions précédentes en convertissant l'essentiel des paquets RPM vers ce nouveau format. Cependant le travail devrait être achevé pour l'ensemble des paquets pour Fedora Linux 41.

La construction de certains paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction. C'est la macro %{hardened_build} qui est étendue pour fournir ce service, cela ne concerne que les paquets l'utilisant. Il peut ainsi générer une telle erreur s'il détecte une pile exécutable, un segment chargeable en mémoire avec des permissions en lecture, écriture et exécutable ou un fil d'exécution local ayant un segment exécutable. L'objectif est donc de renforcer le caractère non modifiable des sections mémoires exécutables pour limiter le risque de failles de sécurité. Cela est fait grâce à l'éditeur de lien BFD qui fournit de telles vérifications. Jusqu'à présent ces cas étaient détectés mais ne généraient que des avertissements qui étaient de fait ignorés.

Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C. L'objectif est de supprimer de plus en plus de code utilisant d'anciennes constructions qui sont source de bogues d'une part, mais qui seront aussi progressivement interdites par défaut avec les futures versions de GCC. Par ailleurs, certains de ces éléments pouvaient être bloquants pour l'adoption d'une nouvelle norme C de référence pour certains paquets.

Voici la liste des changements opérés :

• Suppression des déclarations implicites de fonctions : 54 paquets concernés ;
• Suppression du type implicite int quand le type est omis : 5 paquets concernés ;
• Obligation de mentionner les types dans les arguments lors de la déclaration de fonctions : aucun paquet concerné ;
• Interdiction de conversions implicites entre entier et pointeurs : 100 paquets concernés ;
• L'instruction return doit avoir les arguments qui correspondent au type de retour d'une fonction (donc pas d'argument si void, et non vide si un entier est attendu par exemple) : 13 paquets concernés ;
• Interdiction des conversions implicites de pointeurs de types différents : 381 paquets concernés.

Certains changements devraient voir le jour dans le futur :

• Interdiction des déclarations de fonctions dans le style pré-C89 ;
• Interdiction d'utiliser des mots clés bool, true ou false avec des définitions locales plutôt que d'utiliser l'en-tête de la bibliothèque standard ;
• Déclarer une fonction sans argument comme void foo() aurait le même sens qu'en C++, à savoir équivalent à void foo(void) plutôt qu'à accepter n'importe quel type d'arguments.

Clap de fin pour la construction des mises à jour au format Delta RPM. Ils sont désactivés par défaut dans la configuration de DNF et Fedora ne les générera plus. Cette fonctionnalité permettait pour les mises à jour de ne télécharger que la différence entre le paquet déjà installé et celui à mettre à jour. Cela permettait de réduire la quantité de données à télécharger, la machine de l'utilisateur pouvait reconstruire le paquet à partir de ces informations et ainsi obtenir la nouvelle version. Mais en pratique la fonctionnalité se révèle de moins en moins pertinente. Tout d'abord le processus n'est pas fiable à 100%, parfois la reconstruction échoue et dans ce cas le nouveau paquet est totalement téléchargé à nouveau ce qui conduit à un gaspillage de ressources. De plus peu de paquets étaient concernés, les delta RPM étaient d'ailleurs construits en général que d'une version à une autre ce qui la rend fonctionnelle surtout pour ceux qui mettent à jour très régulièrement leur système. Et pour que cette fonctionnalité soit exploitable, ces fichiers delta rpm font partie des métadonnées que DNF télécharge. Sauf que c'est le cas même si les delta rpm sont désactivés par l'utilisateur, ou pour les systèmes reposant sur rpm-ostree ou utilisant un GUI comme GNOME Logiciels car PackageKit comme rpm-ostree ne se servent pas de ces métadonnées. Au final cela pénalise toute l'infrastructure qui doit générer et stocker ces données, et beaucoup d'utilisateurs qui subissent les inconvénients sans les avantages le tout pour un gain jugé marginal pour ceux qui s'en servent : moins de 8% de réduction de la taille des téléchargements en moyenne.

Les JDKs ne sont générés qu'une fois, et rempaquetés ainsi à toutes les variantes du système. Pour cela les paquets du JDK sont générés à partir de la version la plus ancienne de Fedora Linux encore maintenue, et le résultat est directement réutilisé pour former les paquets des autres versions du système. Cela réduit considérablement le temps de validation de chaque JDK car il y a cinq fois moins de versions différentes à gérer. Cela permettra aux mainteneurs de maintenir la diversité actuelle des JDK à savoir les versions 1.8.0, 11, 17 et la dernière (actuellement la version 20). Si ce résultat ne permet pas de libérer assez de temps aux mainteneurs, la réduction du nombre de JDK à l'avenir pourrait être considérée.

Les images immuables pour les systèmes personnels comme Silverblue seront nommées sous la dénomination Atomic pour éviter la référence au terme immuable qui est confus pour les utilisateurs. Les noms de variantes Silverblue, Kinoite, Sericea et Onyx vont être préservés, l'objectif est de donner une dénomination commune qui utilise le terme Atomic déjà employé par l'édition Cloud par exemple. Le terme immuable est en effet considéré comme peu clair car si le système principal est majoritairement en lecture seule, il ne l'est pas totalement notamment pour la configuration ou les parties dynamiques du système. Alors que le système repose sur le concept d'atomicité en ayant une approche par état du système, d'où la nécessité de redémarrer pour changer cet état notamment lors d'une mise à jour par ailleurs.

L'objectif est donc purement au niveau de la communication autour de ces systèmes. Cependant les nouvelles variantes devraient utiliser ce terme dans ce nom comme par exemple Fedora XCFE Atomic si jamais cette variante prend vie un jour.

La communauté francophone

L'association

Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.

Nous lançons donc un appel à nous rejoindre afin de nous aider.

L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre à travers la France principalement.

Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

• Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
• Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
• Concevoir des goodies ;
• Organiser des évènements type Rencontres Fedora dans votre ville.

Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.

Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuels chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l'avons mis en place en visioconférence sur Jitsi.

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.

Le moins que l'on puisse dire, c'est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège et les autres contributeurs et relecteurs pour leurs contributions.

La synchronisation du travail se passe sur le forum.

Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.

Comment se procurer Fedora Linux 40 ?

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

Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.

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

De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 40.

En ce mardi 26 mars, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 40.

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 40 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 16 ou 23 avril.

Sommaire

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

Expérience utilisateur

• Passage à GNOME 46 ;
• L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6 ;
• Le fichier firefox.desktop est renommé en org.mozilla.firefox.desktop pour permettre son utilisation dans la barre de recherche de GNOME.

Gestion du matériel

• Fourniture de ROCm 6 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques AMD ;
• Passage à l'étape 2 de la prise en charge du noyau unifié nommée UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet.

Internationalisation

• Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30 ;
• Mise à jour de ibus-anthy 1.5.16 pour la saisie du japonais.

Administration système

• NetworkManager tente de détecter par défaut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection avant de l'attribuer à la machine ;
• NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. Cela permet de concilier vie privée et confort d'utilisation ;
• Les unités système de systemd vont utiliser par défaut beaucoup d'options pour améliorer la sécurité des services ;
• Les entrées des politiques SELinux qui font référence au répertoire /var/run font maintenant référence au répertoire /run ;
• L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux ;
• DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets ;
• L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares ;
• Les systèmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise à jour du chargeur de démarrage ;
• Le paquet libuser est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimé ;
• Le paquet cyrus-sasl-ntlm a été supprimé ;
• La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM ;
• Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne ;
• Le serveur LDAP 389 passe de la version 2.4.4 à la version 3.0.0 ;
• Le paquet iotop est remplacé par iotop-c ;
• L'orchestrateur de conteneurs Kubernetes évolue de la version 1.28 à la version 1.29 ;
• Par ailleurs ses paquets sont restructurés ;
• Pendant que podman est mis à jour vers la version 5 ;
• Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version ;
• Le gestionnaire de base de données PostgreSQL migre vers sa 16e version ;
• Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11.

Développement

• Mise à jour de la suite de compilation GNU : GCC 14.0, binutils 2.41, glibc 2.39 et gdb 14.1 ;
• La suite de compilateurs LLVM est mise à jour à la version 18 ;
• Mise à jour de la bibliothèque C++ Boost à la version 1.83 ;
• Le langage Go passe à la version 1.22 ;
• Le JDK de référence pour Java passe de la version 17 à 21 ;
• Mise à jour du langage Ruby 3.3 ;
• Le langage PHP utilise la version 8.3 ;
• La boîte à outils pour le machine learning PyTorch fait son entrée dans Fedora ;
• Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité ;
• La bibliothèque de validation des données Pydantic utilise dorénavant la version 2 ;
• La bibliothèque Thread Building Blocks passe du fil 2020.3 au fil 2021.8 ;
• La bibliothèque OpenSSL 1.1 est supprimée ne laissant que la dernière version de la branche 3.x ;
• Les bibliothèques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant ;
• Le langage Python ne bénéficie plus de la version 3.7.

Projet Fedora

• L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji ;
• Tandis que l'édition Workstation aura son ISO générée avec l'outil Image Builder ;
• L'image minimale ARM sera construite avec l'outil OSBuild ;
• Fedora IoT bénéficiera d'images Bootable Containers ;
• Il bénéficiera également des images Simplified Provisioning ;
• Et le tout sera construit en utilisant rpm-ostree unified core ;
• Fedora sera construit avec DNF 5 en interne ;
• Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros ;
• La construction des paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction ;
• Phase 3 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora ;
• Clap de fin pour la construction des mises à jour au format Delta RPM ;
• Suite du projet de ne générer les JDKs qu'une fois, et les rempaqueter ainsi à toutes les variantes du système ;
• Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C ;
• Les images immuables comme Silverblue seront nommées sous la dénomination Atomic pour éviter la référence au terme immuable qui est confus pour les utilisateurs.

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. Il 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 39 ou 38 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 40.

Bons tests à tous !