User:Renault/Promotion/Fedora Linux 38

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

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 vu comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Cette 38e édition propose principalement une mise à jour de son interface principale GNOME 44 et de l'environnement de bureau plus léger Xfce 4.18. Notons l'arrivée d'images officielles pour les environnements Sway, Budgie et Phosh, ce dernier étant l'interface de GNOME pour mobile !

Bureau de GNOME

Expérience utilisateur

Passage à GNOME 44. Cette version apporte comme d'habitude de nombreuses fonctionnalités pour l'interface par défaut de Fedora Workstation.

Tout d'abord le sélecteur de fichiers permet de voir les fichiers en grille avec prévisualisation, ce qui simplifie la sélection pour l'envoi de photos ou de vidéos par rapport à la vue en liste qui était jusqu'à présent la seule disponible.

Le panneau de configuration bénéficie d'améliorations diverses. Il est possible de partager un mot de passe Wifi par un simple QR code affiché à l'écran. Concernant le réseau les VPN Wireguard sont officiellement pris en charge. La page sécurité de l'appareil est plus simple à comprendre, permettant de savoir en un clin d’œil si la vérification a échoué ou réussi, et le résultat de cette vérification. Le résultat détaillé peut facilement être copié / collé pour l'envoyer sur des forums par exemple.

La page accessibilité a été remaniée également pour être plus simple d'accès. Quelques nouvelles options ont été ajoutées comme la possibilité de sur-amplifier le son au détriment de sa qualité en cas de déficit auditif. Il y a un champ de test pour la configuration du clignotement du curseur de souris ou encore la possibilité de toujours voir la barre de défilement sur le côté.

La page son permet de désactiver le son d'alerte, la liste des alertes a d'ailleurs été déplacée dans une fenêtre popup. La page de test du son s'adapte mieux aux différentes tailles d'écran.

La page souris et pavé tactile a été entièrement réécrite. Des vidéos montrent la direction du défilement pour rendre l'explication plus claire à l'utilisateur. De même pour les tests des paramètres, la page a été refaite pour être plus simple et complète.

Pour le reste, le menu principal affiche la liste des applications en arrière plan, pour l'instant seules les applications Flatpak sont concernées. L'application Logiciels est plus réactive et elle supprime automatiquement les runtimes Flatpak quand ils ne sont plus nécessaires. Le logiciel Fichiers quant à lui réintroduit la vue expansion de dossiers qui avait été brièvement supprimée lors du passage à GTK4. Il est maintenant possible de déplacer un onglet vers une autre fenêtre.

Le navigateur Web de GNOME passe d'ailleurs à GTK4 ce qui améliore la cohérence de l'interface avec le reste de l'écosystème et sa réactivité. Une fenêtre popup surgit pour enregistrer ou non un mot de passe lors de la connexion à un site web.

La petite souris Xfce est mise à jour après 4.18 tours de roue. Cette version apporte aussi de nombreux changements pour sa communauté comme l'amélioration du renommage des fichiers dans Thunar pour remonter des erreurs ou avoir de long noms de fichier. Ce dernier comme le terminal ou l'éditeur de texte peuvent voir leur raccourcis clavier personnalisés dans leurs préférences. Les miniatures de fichiers sont générées plus rapidement.

Le navigateur de fichiers affiche le nombre de fichiers dans un répertoire lors d'une vue en liste, la colonne de date de création d'un fichier est également disponible. Les dix dernières opérations sur les fichiers peuvent être annulées ou effectuées à nouveau. Chaque fichier peut être mis en évidence avec une couleur spécifique en fond. Sa barre des tâches peut être personnalisée. Elle bénéficie d'une vue scindée au sein d'une même fenêtre pour voir deux dossiers différents en même temps. Par ailleurs, elle permet la recherche récursive dans les dossiers ou de voir les derniers fichiers récemment utilisés.

Le tableau de bord fusionne DateTime et l'horloge pour les préférences concernant l'heure et le calendrier pour supprimer des doublons. L'horloge dispose par ailleurs d'un affichage alternatif en binaire.

Le gestionnaire de configuration comme pour GNOME bénéficie de certains changements. Il est possible de décider quelle action effectuer quand un nouvel écran est branché.

Enfin, le gestionnaire de fenêtres permet la synchronisation verticale de son affichage. Une meilleure mise à l'échelle de l'interface est également proposée.

Le gestionnaire de connexions SDDM (utilisé par KDE par exemple) utilise Wayland par défaut. Cela signifie que le spin KDE Plasma et Kinoite ont fini leur transition vers Wayland par défaut. Cela a été rendu possible grâce au travail en amont pour le permettre au sein de SDDM, mais aussi aux changements opérés dans Fedora Linux 36 qui a remplacé fbdev par simpledrm pour la gestion de l'affichage en cas d'absence de pilote vidéo dédié.

L'image Fedora Linux avec le bureau Budgie devient une image Spin officielle. Cela permet de simplifier la découverte de ce bureau moderne d'une part en le mettant en avant et en facilitant son installation. Sa communauté pourra également l'installer plus rapidement tout en n'ayant pas des composants inutiles par ailleurs.

De même pour l'image Fedora Linux avec le gestionnaire de fenêtres Sway. Cela fourni les mêmes avantages que pour Budgie, avec en plus le bénéfice que Sway, en tant que i3 sous Wayland, peut être exploité sur des machines très minimalistes en puissance ce qui rend son installation directe plus pertinente encore.

L'utilitaire initial-setup n'est plus fourni dans l'image KDE et l'image Kinoite. Cette application est centrée sur GNOME pour permettre la création de l'utilisateur et quelques paramètres après l'installation, en particulier pour les installations OEM. L'objectif sera de le remplacer plus tard par un utilitaire plus adapté à l'interface de KDE Plasma, en attendant c'est Anaconda qui prend en charge ces paramètres lors de l'installation.

Flathub n'est plus filtré par défaut lors de l'installation de Fedora Linux, tous les paquets proposés sont donc accessibles. Depuis Fedora Linux 35, Flathub est proposé comme un dépôt tiers facilement activable pour récupérer des paquets Flatpak provenant de ce dépôt sans manipulations supplémentaires. Cependant il y avait un filtrage pour supprimer les applications propriétaires, ou les doublons, etc. Cependant cela rendait confus les utilisateurs qui n'avaient pas accès à tout le dépôt et rendait plus difficile la tâche de ceux qui voulaient accéder à ce dépôt en entier.

Le filtre est donc supprimé, pour éviter les effets de bords GNOME Logiciels doit proposer dans l'ordre les Flatpak de Fedora, les paquets RPM de Fedora puis les Flatpak de Flathub (ou autre dépôts) par défaut si un logiciel est disponible sous ces formats là. GNOME Logiciels doit garantir de rendre clair le fait que le logiciel à installer est propriétaire ou libre.

Pour rappel, ce dépôt Flathub n'est pas actif par défaut.

Le timer systemd pour l'extinction de la machine passe de 2 minutes à 45 secondes, envoyant un signal SIGABRT puis un SIGKILL si jamais des services n'ont pas réussi à s'arrêter dans ce délai. En effet un service bloqué dans cette procédure pouvait bloquer le redémarrage ou l'extinction de la machine pendant 2 minutes ce qui est particulièrement long et souvent dû à un problème comme le service PackageKit qui est souvent concerné par cette problématique.

Il a été suggéré de baisser cela à 15 secondes, mais cela a été jugé trop agressif pour une première baisse de la durée. L'objectif est d'observer le résultat avec 45 secondes avant d'envisager une baisse supplémentaire. Les services pouvant être longs à s'éteindre dans leur comportement normal peuvent de toute façon désactiver ce temps d'attente ce qui est le cas de PostgreSQL ou de virt-manager pour éviter de mauvaises surprises pour des systèmes qui en ont besoin. Les utilisateurs qui en ont besoin sur leurs services peuvent se renseigner au sujet de XDG inhibit pour les applications ou de systemd inhibit pour les services.

cups-filters passe à la version 2.0b. Cette nouvelle version est essentiellement un redécoupage des composants avec cups-filters, libcupsfilters, libppd, braille-printer-app et cups-browsed. L'objectif est de rendre la prise en charge du format PPD indépendant du reste pour une éventuelle suppression future quand il ne sera plus pris en charge ce qui est planifié pour CUPS 3.X. Les applications spécifiques des constructeurs seront dès lors nécessaires, mais l'avènement de l'impression sans pilotes rend cette contrainte future de moins en moins gênante en pratique.

Dans le domaine de l'impression le paquet ipp-usb devient une dépendance faible de cups ou de sane-airscan pour proposer la prise en charge des imprimantes USB par défaut sans installation supplémentaire de la part de l'utilisateur. En effet de nombreuses imprimantes proposent de nos jours une prise en charge sans pilotes spécifiques pour l'impression via le réseau, mais aussi par USB via le protocole IPP over USB ce que prend en charge le paquet en question. Par conséquent un utilisateur qui souhaite imprimer ou scanner (et même faxer) aura par défaut une possibilité supplémentaire de s'en servir sans devoir chercher les paquets manquants éventuels. Ceux qui n'en veulent pas pourront toujours supprimer ce paquet dans ce cas précis.

La distribution LaTeX TeXLive version 2022 est proposée, qui est la dernière version avec une prise en charge longue durée. L'ancien cache personnel devrait être supprimé pour s'assurer du fonctionnement, à savoir supprimer le répertoire ~/.texlive2021.

Gestion du matériel

L'installateur Anaconda utilise mdadm au lieu de dmraid pour la prise en charge des stockages RAID reposant sur un firmware ou un BIOS. En effet ce dernier n'est plus très maintenu ce qui pose des soucis pour la correction de bogues ou de failles de sécurité. D'ailleurs mdadm est plus utilisé par les logiciels de gestion des configurations RAID de nos jours. Cependant mdadm ne prend en charge que deux formats de RAID : Common RAID Disk Data Format (DDF) par SNIA et Intel Matrix Storage Manager. Cela signifie que les formats RAID gérés matériellement les plus anciens ne seront pas forcément pris en charge par Anaconda.

L'image LXQt est proposée pour l'architecture aarch64. Le bureau étant particulièrement léger, cela le rend pertinent de le proposer pour cette architecture directement.

Fourniture d'une image avec Phosh, GNOME Shell pour mobile, à destination des téléphones ou des tablettes pour l'architecture x86_64 et aarch64. Cette interface proposée par l'entreprise Purism peut tourner sur des téléphones ou tablettes si les noyaux classiques permettent une telle prise en charge native. Proposer une image dédiée permet cette installation et rend cette action plus facile.

L'architecture s390x utilise les processeurs de la génération z13 comme base, les plus anciens ne seront plus forcément compatibles. Les processeurs de générations antérieures ne sont plus prises en charge par le fabricant. Et l'architecture z13 propose des instructions vectorielles dont il est possible de tirer profit sur l'ensemble des logiciels grâce aux nouvelles options de compilation, ce qui était impossible par la prise des modèles plus anciens.

Les implémentations du serveur X (Xorg et Xwayland) refusent par défaut à des clients ayant un boutisme différent du serveur de s'y connecter. Il devient donc impossible par défaut d'utiliser un client X avec un processeur Intel pour afficher une interface provenant un serveur X sous processeur s390x. En effet ce cas de figure particulier est difficile à prendre en charge en l'état actuel du code, il est peu testé et est source d'une grande surface d'attaque pour un usage considéré comme marginal. Le désactiver par défaut permet de protéger les utilisateurs qui n'en ont pas besoin contre des clients malveillants. Cependant pour ceux qui en ont réellement besoin, il est possible de le résoudre via l'option de configuration AllowByteSwappedClients dans le fichier xorg.conf ou par l'usage de l'option +byteswappedclients en démarrant le serveur X.

Première partie de la migration vers une image noyau unifiée 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 est de rendre le démarrage du système plus sûr, robuste et uniforme car moins dépendant des spécificités de chaque système, idéalement avec un tel système, le noyau, l'initrd et la ligne de commande seraient uniques sur tous les systèmes Fedora Linux.

Cependant c'est irréaliste de tout faire en une étape, trop de choses dépendent encore de la méthode actuelle à savoir l'initrd qui est générée à partir de l'ordinateur de l'utilisateur qui se base notamment sur les pilotes actuellement chargés par le système. Le plan a été phasé ainsi :

• Phase 1 : fournir les blocs de base, à savoir pouvoir installer, démarrer et mettre à jour de tels fichiers, pour permettre de développer et de tester des images UKIs en machine virtuelle ;
• Phase 2+ : étendre la prise en charge en gérant de plus en plus de cas d'usage un par un ;
• Phase X : une fois qu'il y a parité avec les noyaux non-UKI, discuter de l'usage par défaut pour tous les cas d'usage. En particulier les images cloud ou serveurs pourraient y passer plus tôt car ils ont moins de contraintes quand le système est virtualisé.
• Non prévu : la suppression des images non UKI.

Pour ceux qui veulent tester en machine virtuelle, le paquet kernel-uki-virt est proposé à cette fin. Dans les difficultés à résoudre il y a la question des secrets matériels provenant de l'UEFI qu'il faut récupérer, il y aussi la partition où se situe la partition système qui doit être auto-détectée ce qui est possible grâce à la norme UEFI. En effet, chaque partition a un type défini sous forme de UUID unique ce qui nous renseigne sur sa nature. Ou encore la question des options particulières à envoyer au noyau pour configurer le système, utilisées par exemple pour éviter le conflit entre le pilote libre ou propriétaire de nVidia.

L'installateur de l'image IoT récupère celui de CoreOS pour simplifier son installation. Ainsi c'est une simple image OSTree qui peut être écrite sur l'espace de stockage via un argument noyau à spécifier. Pas besoin d'utiliser l'outil kickstart ou une quelconque manipulation supplémentaire. L'avantage c'est de simplifier l'installation pour des systèmes avec une connexion Internet lente ou non fiable, l'installation se faisant en une fois après que l'image ait été entièrement récupérée. Cela rapproche également Fedora IoT de l'image de RHEL dédiée à cet usage.

Internationalisation

La police par défaut pour la langue thaï et le cambodgien passe à Noto. Ces langues rejoignent ainsi celles qui avaient déjà effectué ce changement pour Fedora Linux 36 ce qui réduit la taille du système d'environ 344 kio dans ce cas et rend l'affichage plus cohérent pour l'ensemble des langues. La qualité d'affichage devrait aussi être meilleure pour ces langues.

Tandis que les polices Noto CJK pour les langues chinoises, japonaises et coréennes utilisent la variante variable au lieu de static comme auparavant. Cette variante est en effet plus légère d'un facteur deux environ, de quoi gagner plusieurs dizaines de Mio sur le système par défaut et sur les images Live.

Mise à jour de libpinyin 2.8. Ce gestionnaire d'entrée de saisie pour la langue chinoise ajoute la proposition d'expressions candidates à partir de l'entrée en cours. Cela permet d'accélérer la saisie dans cette langue.

Administration système

Les clés du serveur SSH suppriment le droit de lecture par les utilisateurs du groupe ssh_keys, qui est supprimé au passage, pour rétablir le SUID bit de l'utilitaire ssh-keysign. Cela revient à supprimer un correctif spécifique de Fedora qui date de 11 ans, ce correctif échangeait le setuid du compte root avec une permission sur ces fichiers 0600 par un sgid associé au groupe ssh_keys mais des permissions plus lâches à savoir 0640. La raison derrière ce changement n'a pas été documentée et semble perdue, cependant de plus en plus d'utilitaires, notamment pour l'authentification basée sur l'hôte, font des vérifications de ces permissions et cette déviation par rapport à une installation OpenSSH standard était source de problèmes difficiles à justifier.

RPM utilise Sequoia pour traiter le format OpenPGP au lieu de sa propre implémentation interne. Pendant près de 20 ans, toute la partie pour gérer OpenGPG était développée en interne. Cela avait plusieurs inconvénients, évidemment en terme de sécurité car ce code sensible était pris en charge par des développeurs pas experts du domaine. Mais aussi le temps de développement étant limité, améliorer la prise en charge d'OpenGPG était au détriment du reste. Le tout pour une implémentation imparfaite de la norme RFC 4880. Ce changement ouvre la possibilité d'améliorer les messages d'erreurs relatifs aux signatures des paquets à l'avenir.

Le paquet systemd-udev fourni par défaut la règle Link.MACAddressPolicy=none au lieu de Link.MACAddressPolicy=persistent pour les interfaces réseaux logiciels ponts ou agrégées. Cette information est fournie dans le fichier /usr/lib/systemd/network/99-default.link. La configuration reste inchangée pour les interfaces réseaux logiciels plus classiques ce qui garanti une stabilité dans l'assignation des adresses MAC. Ce changement a été décidé suite aux interférences avec le comportement du noyau Linux dans ce cas de figure qui utilise l'adresse MAC de la première interface. Cela peut aussi affecter les machines virtuelles qui s'attendent à ce que le pont ou l'agrégation de liens ait une des adresses MAC des interfaces réseaux impliquées.

Le gestionnaire de paquet Microdnf est mis à jour à sa 5e version. Il est à terme prévu que microdnf devienne l'implémentation de référence de dnf, le gestionnaire de paquets actuel de Fedora Linux, et ce peut être même dès Fedora Linux 39. Cette version majeure rapproche l'objectif d'une compatibilité des deux outils tout en gardant une taille plus raisonnable. Il est disponible sous le nom de paquet dnf5. Cette version améliore l'affichage des bars de progression et la gestion des transactions. L'exécution des scriptlets (les scripts avant ou après l'installation / suppression d'un paquet à des fin de conversion ou de nettoyage) est aussi affichée. Les opérations impliquant des RPM locaux est aussi améliorées de même que l'auto-complétion des commande fournie par le shell Bash qui devient meilleure que celle de dnf lui même. La gestion des dépôts modulaires est également totalement intégrée, les plugins C++ et Python sont mutualisés pour réduire le coût de maintenance. Les performances sont également améliorées dans l'ensemble parmi d'autres changements plus mineurs.

Développement

La mise à niveau de la chaine de compilation GNU est à l’œuvre avec GCC 13.0, binutils 2.39, glibc 2.37 et GDB 12.1. GCC bénéficie ainsi d'une meilleure prise en charge de l'évolution de la norme du langage C dénommée C23. De même par ailleurs pour le langage C++ avec C++23. Sinon c'est l'analyseur statique de code qui bénéficie de nouveaux avertissements plutôt nombreux. Les architectures x86 et ARM ou Aarch64 bénéficient comme souvent d'une meilleure prise en charge des spécificités des différentes micro-architectures dans ces familles.

Concernant binutils, l'éditeur de lien ELF va émettre un avertissement pour des raisons de sécurité si la pile est exécutable. La commande objdump a sa sortie de désassemblage qui est colorée syntaxiquement pour favoriser sa lecture pour les architectures AVR, RiscV, s390, x86 et x86_64. La bibliothèque C bénéficie essentiellement de corrections plus mineures dont de sécurité.

Enfin pour le débogueur, l'architecture LoongArch est prise en charge, pendant que celle d'OpenRISC s'améliore. Sinon l'API des plugins de Python s'étoffe de même que la gestion des templates C++.

Retrait de la prise en charge du langage Guile pour étendre GDB pour laisser la place à Python pour cela. La prise en charge de Guile est en effet en déclin, elle est moins complète que Python qui est de plus en plus utilisée et améliorée à cette fin. La documentation de GDB met d'ailleurs en avant Python plutôt que Guile dans cette tâche, ce qui peut laisser à penser qu'un jour cette prise en charge de Guile sera supprimée à terme. Anticiper ce mouvement permet de simplifier la tâche des mainteneurs.

Pendant que LLVM version 16 débarque. Cette mise à jour s'accompagne d'abord d'une amélioration de la prise en charge des architectures, avec les nouveaux processeurs AMD Zen 4 ou Intel Emerald Rapids. L'architecture RISC V bénéficie des options -mcpu=native / -mtune=native pour une mise au point plus fine. Le compilateur JIT prend en charge le langage OpenMP. Il peut également compresser avec l'algorithme Zstd les sections de débogage ELF.

GNU Make prépare sa version 4.4. Il y a beaucoup d'annonces de rupture de la compatibilité ascendante, dont l'usage plus important du répertoire temporaire ce qui peut casser tout script manipulant ou nettoyant TMPDIR. Il apporte l'ajout d'une nouvelle cible .WAIT pour permettre d'attendre la fin de l'exécution de plusieurs cibles avant de débuter le traitement d'une nouvelle. L'option -l va utiliser l'information exposée dans le fichier /proc/loadavg pour définir le nombre de tâches à exécuter en parallèles.

Le langage Go quant à lui passe à la version 1.20. Cette version apporte le début de la prise en charge du PGO (profile-guided optimization) pour se baser sur des données collectées à l'exécution d'un logiciel pour que le compilateur puisse recompiler ce logiciel par la suite autrement afin d'en optimiser ses performances, jusqu'à 3-4 % d'amélioration pour le moment. Par ailleurs les performances d'un logiciel Go en terme de pression mémoire et d'utilisation du processeur sont améliorées par une optimisation du ramasse miettes, pouvant aller jusqu'à 2% d'amélioration. Il est également possible de régler la micro-architecture cible à la compilation pour améliorer les performances en utilisant les fonctionnalités du processeur cible.

Le langage Ruby expose sa version 3.2 en vitrine. Son nouveau compilateur JIT nommé YJIT n'est plus considéré comme expérimental et est d'ailleurs plus performant jusqu'à 41% par rapport à la version précédente. YJIT alloue maintenant la mémoire de manière paresseuse et fonctionne aussi sur les architectures ARM et Aarch64. Les expressions régulières bénéficient d'une amélioration notable des performances pour une évaluation de la correspondance qui devient linéaire par rapport à la taille des entrées et si l'évaluation est trop lente, un timeout est généré basé sur la valeur de configuration Regexp.timeout. L'objectif était d'éviter une dégradation trop importante des performances dans certains cas, notamment dans un cadre malveillant.

Le langage PHP évolue vers la version 8.2. Cette version apporte entre autre la possibilité de définir des classes en lecture seule. Les types null, false et true deviennent des types autonomes. Les types de forme normale disjonctive sont pris en charge pour faciliter l'expression des unions et intersections de types pour faciliter la lecture et l'écriture de code.

Le gestionnaire de base de données PostgreSQL met à jour à la version 15. Cette version apporte la prise en charge de la commande SQL MERGE. L'algorithme de compression Zstd peut être employé également notamment pour les sauvegardes. Les journaux côté serveur peuvent être exportés au format JSON. Enfin les performances sont améliorées en particulier pour les opérations de tris.

Pendant que Haskell GHC (le compilateur Haskell) 9.2 avec sa suite Stackage 20 sont disponibles. Du côté des performances, les architectures Aarch64 et s390x bénéficient d'une amélioration de ce côté. Pour le premier grâce à une prise en charge native par le compilateur GHC au lieu de LLVM utilisé jusqu'à présent. Pour le second par l'usage du système de construction Hadrian fourni par LLVM. Le langage lui même évolue, en proposant les types LinearTypes ou ImpredicativeTypes ou encore UnliftedDatatypes.

L'écosystème Node.js est repackagé pour autoriser des installations multiples et parallèles, abandonnant l'usage des modules qui était la voie privilégiée jusqu'ici. En effet, si les modules permettent de changer la version d'un paquet sans changer de version de Fedora Linux, il ne permet pas l'installation parallèle ce qui est embêtant particulièrement pour l'écosystème JavaScript qui évolue rapidement et dont le test sur plusieurs versions est nécessaire. Le travail est ainsi rendu plus simple pour le développeur sans l'usage de conteneurs. Par ailleurs la maintenance pour Fedora Linux était globalement plus complexe. Le paquet nodejs renvoie actuellement à la version 18.15, tandis que les paquets nodejs16 et nodejs20 fournissent respectivement la branche 16.x ou 20.x.

La bibliothèque pcre est marquée comme obsolète au bénéfice de pcre2, sa suppression totale des dépôts (et de ses dépendances) est à prévoir prochainement. En effet sa dernière version 8.45 sortie en juin 2021 est la dernière, ce qui signifie qu'aucun bogues ou failles de sécurité associés ne seront corrigés. Cela concerne encore 67 paquets dans les dépôts qui n'ont pas achevé la transition.

OpenJDK est compilé pour ressembler plus aux implémentations standards de JDK avec les bibliothèques internes au lieu de celles du système et la compilation avec la bibliothèque libstdc++ liée statiquement. Cela signifie que les options de compilation dorénavant utilisées sont les suivantes : --with-stdc++lib=static --with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" --with-harfbuzz="bundled". L'objectif est de réduire les différences entre les JDK depuis Fedora Linux et les autres systèmes. Ces différences étaient coûteuses à maintenir pour Fedora Linux notamment pour certifier le résultat de chaque version de JDK que Fedora Linux propose ce qui ralentie les mises à jour mais aussi la correction d'autres bogues. Mais en contrepartie, OpenJDK ne tire plus bénéfice du partage de ces bibliothèques avec le reste du système notamment en consommation de ressources ou corrections liées à ces bibliothèques.

La boîte à outils pour le développement Web en Python nommé Pyramid bénéficie de la version 2.0. Tout d'abord cette version n'est compatible qu'avec Python 3. D'un point de vue fonctionnel, son changement majeur est la fusion des politiques d'authentification et d'autorisation au sein d'une politique unique. L'ancienne méthode reste disponible pour des raisons de compatibilité ascendante.

Mise à jour de python-packaging version vers la version 22.0. Les paquets utilisant LegacyVersion ou LegacySpecifier ne peuvent plus être générés tels quels et doivent se conformer à la PEP 440 ce qui améliore la compatibilité avec le reste de l'écosystème Python.

Le paquet python3-toml est considéré comme obsolète avant suppression définitive à venir depuis la prise en charge de cette fonctionnalité dans la bibliothèque standard depuis Python 3.11. Cela signifie qu'aucun nouveau paquet ne pourra dépendre de lui et qu'une étape de conversion progressive des dépendances actuelles est en cours. Ce qui peut permettre par ailleurs de bénéficier des évolutions du standard TOML, non pris en charge par ce même paquet. À cause des divergences d'API et de nommage, la transition de l'un vers l'autre n'est pas trivial et ne peut reposer sur un paquet python3-toml qui pointe vers python3-libs ou python3 directement.

Le paquet du compilateur FreePascal fpc est subdivisé en trois paquets : fpc pour le compilateur lui même, fpc-ide pour l'environnement de développement en ligne de commande et fpc-units-NOMARCHITECTURE-linux pour la bibliothèque standard précompilée. Les utilisateurs peuvent se contenter d'installer uniquement ce dont ils ont besoin.

Le générateur d'interface SWIG se balance vers la version 4.10. Ses évolutions dans la prise en charge des langages sont multiples. Côté Nodejs il peut fournir maintenant pour la version 12 à 18, tout en supprimant la prise en charge des versions antérieures à version 6. Octave 6.0 et 6.4 sont fournis également, tout comme PHP 8 qui perd par contre les versions plus anciennes que la version 5.8. Côté Python c'est 3.3 la version minimale supportée, jusqu'à la version 3.11. Les évolutions de C et C++ sont également mieux prises en charge avec notamment le début de compatibilité avec C++20 et de std::unique_ptr.

L'utilitaire ImageMagick tire profit de sa 7e version. Cette version n'est pas compatible avec l'ancienne version 6. Elle bénéficie de nombreux changements comme la prise en charge native des images HDRI. La structure de donnée Pixel Channels a été totalement remaniée, au lieu d'en avoir 4 définie dans PixelPacket (pour rouge, vert, bleu et l'opacité) et d'autres éventuellement comme le niveau de gris, ou l'index des couleurs dans IndexPacket, maintenant il peut y en avoir 1 à 64 par pixels définis ensemble. Cela rend le code plus générique et plus clair, mais aussi autorise le compilateur d'optimiser le code dans les boucles de traitement en particulier. Beaucoup de fonctions sont fournies autour de cela pour faciliter leur utilisation et rendre le code plus générique. L'opacité devient aussi un canal `alpha´ ce qui inverse la logique, une opacité de 0 signifie opaque, quand c'est totalement transparent pour alpha. Mais cela correspond mieux à la terminologie habituelle pour manipuler des pixels dans une image. Les API ont été remaniées pour prendre en compte ces changements de conception, d'où la rupture de compatibilité.

Projet Fedora

La génération des images Fedora IoT reposera sur osbuild. Cela permet de corriger le retard pris par cette édition de Fedora Linux par rapport à RHEL for Edge qui est son équivalent proposé par Red Hat ce qui facilitera notamment les travaux communs.

Les paquets sont compilés avec l'option _FORTIFY_SOURCE=3 au lieu de _FORTIFY_SOURCE=2 pour mieux se protéger contre les buffers overflow dans les logiciels fournis. Cela concerne des fonctions au sein de la bibliothèque glibc qui concernent beaucoup plus de fonctions avec cette nouvelle édition. Notons que cela a déjà été mis en place du côté de chez Swann, de Gentoo ou de OpenSUSE par exemple.

Les paquets sont également compilés avec les options -fno-omit-frame-pointer et -mno-omit-leaf-frame-pointer par défaut. L'objectif est d'améliorer le profilage et le débogage des paquets ainsi compilés, ce qui est particulièrement utile pour vérifier les performances des logiciels ayant beaucoup de dépendances. Une baisse de performances est cependant possible bien que faible d'après les essais préliminaires menés et les retours du terrain chez Google. Les résultats étant en résumé :

• La compilation du noyau Linux avec GCC est 2,4% plus lente ;
• Le rendu effectué par Blender peut être jusqu'à 2% plus lent ;
• OpenSSL, Botan, Zstd ou Redis n'ont pas d'impacts mesurables ;
• Les tests spécifiques de CPython peuvent avoir une perte de 1 à 10% suivant les tests.

Les paquets qui veulent changer leur option de compilation doivent passer par les macros %_pkg_extra_cflags, %_pkg_extra_cxxflags, %_pkg_extra_fflags et %_pkg_extra_ldflags pour plus de lisibilité et de traçabilité. L'objectif est d'avoir un moyen standard et unifié de personnaliser ces options de compilation pour l'ensemble des paquets ce qui simplifie la lisibilité et donc la maintenance. Les mainteneurs de la chaine de compilation peuvent plus facilement expérimenter en utilisant ces options plutôt que de changer redhat-rpm-config directement. Enfin il est possible de voir tous les paquets qui personnalisent la compilation ainsi par des requêtes assez simples.

La macro rpmautospec (qui emploie les macros %autorelease et %autochangelog) est recommandée pour l'ensemble des paquets par défaut. En effet, introduit par Fedora Linux 35, seulement 3423 paquets sur 23045 s'en servaient soit environ 15% d'entre eux. Les avantages attendus sont multiples, les mainteneurs n'ont plus à toucher au champ Release qui est généré automatiquement, le commit pour générer le nouveau paquet permet de remplir le champ changelog automatiquement ce qui fait gagner du temps au mainteneur. Comme ces champs sont générés par une macro à la construction, il est plus simple de réutiliser une mise à jour du fichier spec entre les différentes version de Fedora Linux car les conflits sont moins nombreux, de même pour les pull requests vers src.fedoraproject.org qui ont moins de conflits.

Activation de la macro %clamp_mtime_to_source_date_epoch à 1 qui configure mtimes (le temps de modifications des fichiers) en $SOURCE_DATE_EPOCH pour la compilation reproductible des paquets. La date est ainsi liée à la date du dernier champ dans la macro %changelog. Il devient ainsi beaucoup plus simple de faire de la compilation reproductible car l'information est facilement disponible et n'est pas altérée par l'heure où le paquet a été effectivement construit. Cependant la compilation reproductible n'est pas complète au sein du projet Fedora encore.

La macro pour gérer les dépendances des modules Perl perl(:MODULE_COMPAT_%(eval "%{__perl} -V:version"; echo $version)) est supprimée au profit de perl-generators. L'objectif est de réduire le besoin de recompilation des paquets Perl à chaque mise à jour de Perl pour ne concerner que les paquets qui en ont besoin, soit à cause d'une rupture de compatibilité ou parce qu'ils contiennent eux même du code compilé qui en dépendent directement. Cela simplifiera beaucoup la tâche des mainteneurs Perl, en passant de 3259 paquets impactés par ces mises à jour à environ 600.

Les paquets Python fournissant la métadonnée python3dist(...) = 0 échoueront dans leur construction. Il était parfois employé par les paquets quand la version exigée par le programme n'était pas connue mais cela relevait souvent d'une erreur du mainteneur des paquets. Cela pouvait générer des problèmes, par exemple si un paquet dépend de python3-ssh-python > 0.9 alors que la version de ce paquet 0.10.0 est disponible dans les dépôts, le générateur automatique de dépendances ne va pas identifier le paquet et générer des erreurs lors de la résolution des dépendances. Au moment de la décision d'effectuer ce changement, seulement 10 paquets étaient ainsi construits mais cela évitera que ce problème n'apparaisse également encore dans le futur.

Début 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, de manière facultative pour l'instant. En effet au sein du projet Fedora si les licences sont bien renseignées, leur usage n'était pas totalement uniforme avec des variations possibles entre les paquets ou des imprécisions dans leur mention. Le projet SPDX commence à s'imposer comme une référence dans la résolution de ce problème avec une nomenclature standardisée et en étant largement adopté par le noyau Linux, Debian, OpenSUSE ou FreeBSD. Cela rendra également le travail de Fedora Legal et de la documentation autour des licences plus simple.

Par exemple le paquet tmux avait pour champs de licence ISC and BSD qui devient maintenant ISC AND BSD-3-Clause AND BSD-2-Clause ce qui met en exergue une meilleure précision.

À ce jour environ 20% des paquets ont été convertis. Et les nouveaux paquets devront dès le départ utiliser cette nomenclature. Le reste devrait suivre pour Fedora 39 maintenant que les outils et la procédure sont en place.

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, José Fournier 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 38 ?

Si vous avez déjà Fedora Linux 37 ou 36 sur votre machine, vous pouvez faire une mise à niveau vers Fedora Linux 38. 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 38.