En ce mardi 7 novembre, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 39.
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 39e édition propose principalement une mise à jour de son interface principale GNOME 45, de sa suite bureautique LibreOffice 7.6 et l'abandon des thèmes personnalisés pour les logiciels utilisant la bibliothèque graphique Qt. Notons l'arrivée d'images officielles pour l'environnement Budgie dans un système immuable nommé Onyx.
Sommaire
- Expérience utilisateur
- Gestion du matériel
- Internationalisation
- Administration système
- Développement
- Projet Fedora
- La communauté francophone
- Comment se procurer Fedora Linux 39 ?
Expérience utilisateur
Passage à GNOME 45. Cette nouvelle version de l’environnement de bureau GNOME apporte de nombreux changements dont le bouton Activité, situé au coin en haut à gauche, qui laisse place à un bouton indiquant les bureaux virtuels de l’environnement et met en évidence celui qui est actuellement affiché. La performance globale de la recherche dans les applications GNOME a été améliorée, en particulier pour le navigateur de fichiers nommé Fichiers et la logithèque nommée Logiciels. À côté du menu principal, en haut à droite de l’interface, un indicateur de caméra s’active si une caméra est actuellement utilisée par une application compatible Pipewire. Cela rejoint l’indicateur existant pour le microphone pour s’assurer qu’ils sont actifs quand cela est nécessaire uniquement.
Dans les ajouts plus mineurs, il est possible de régler la luminosité du clavier pour les matériels compatibles. La lecture de vidéos va mieux utiliser le décodage matériel pour diminuer la consommation d’énergie et améliorer les performances du système. La barre principale peut dorénavant avoir une teinte claire contrairement au style par défaut depuis GNOME 3, il peut être activé via la commande suivante
$ gsettings set org.gnome.desktop.interface color-scheme prefer-light
Son intégration future dans l’interface est prévue.
Le curseur de souris est également restylisé et son déplacement sera plus doux et consommera moins de ressources. Le visionneur d’image par défaut Eyes of GNOME fait place à son successeur Image Viewer, il est plus performant, son interface est plus adaptative pour un usage sur téléphone et son exploitation des touchpads et écrans tactiles est meilleure. De même une nouvelle application de caméra fait son apparition pour une meilleure intégration dans l’interface et sur écrans de tailles différentes.
La plupart des interfaces logicielles ont un style légèrement redessiné et sont plus adaptatives.
La suite bureautique LibreOffice est mise à jour vers sa version 7.6. La compatibilité avec les fichiers de Microsoft Office est comme d’habitude améliorée. Les recommandations d’accessibilité sont déplacées sur le panneau latéral pour être plus facilement accessibles durant l’édition du document. Les entrées d’un dictionnaire Hunspell avec plusieurs mots comme des noms propres ou des locutions avec plusieurs mots sont maintenant prises en charges. L’aide affiche maintenant tous les emplacements où une fonctionnalité peut être accédée : menus, raccourcis claviers, bouton dans la boîte à outils, ou depuis la barre de statut, etc. Il y a également la prise en charge des thèmes d’un document. Enfin, utiliser le pincement sur un touchpad permet de zoomer le document.
Le shell Bash dispose par défaut d’un prompt coloré pour le rendre plus distinct des commandes. Par défaut la couleur est le vert, cela permet de simplifier la distinction du prompt par rapports aux commandes notamment lors de la navigation parmi les commandes et sorties précédentes. Le prompt reste monochrome, en dehors du code d’erreur de la commande précédente qui est affiché en fin de prompt avec une couleur rouge.
Clap de fin pour le thème personnalisé par Fedora pour la bibliothèque graphique Qt. Ce thème par défaut permettait de s’approcher visuellement du thème des applications GNOME pour améliorer l’intégration. Cela reposait sur les composants QGnomePlatform et Adwaita-qt, l’objectif est d’essayer plutôt d’améliorer cela au niveau de Qt lui-même. Cette solution était en effet complexe, source de bogues et de soucis d’expérience utilisateur en particulier depuis la progression du thème Adwaita avec GTK4 qui n’a pas été suivi et est complexe à mettre en œuvre dans ce contexte.
Les spins Sericea et Sway seront fournis sans X.org par défaut. En effet l’environnement Sway est compatible uniquement avec Wayland et non avec X11, cela fait donc sens de supprimer ce composant. Il était maintenu à cause du gestionnaire de connexions SDDM qui n’était pas suffisamment stable avec Wayland à l’époque, mais la situation s’est également améliorée de ce côté.
Le spin de l’environnement Budgie dispose d’une variante immuable nommée Onyx. Il devient ainsi la 4ᵉ variante bureautique immuable de Fedora, après Fedora Silverblue (avec GNOME), Fedora Kinoite (avec KDE Plasma) et Fedora Sericea (avec Sway).
La variante Fedora Kinoite propose par défaut des mises à jour automatiques de la base de son système. Cela repose sur rpm-ostree et l’application de la mise à jour se fait au redémarrage suivant. La fréquence de mise à jour comme l’activation de cette mise à jour automatique restent personnalisables.
Le jeu d’icônes FontAwesome est proposé à la version 6.3.0. Un paquet de compatibilité avec la version 4 reste disponible en cas de besoin sous le nom de _ fontawesome4-fonts_. Cela permet aux applications s’en servant d’avoir une interface plus proche de ce qui a été développé.
Gestion du matériel
Possibilité d’installer Fedora Linux avec systemd-boot au lieu de GRUB comme chargeur de démarrage. Cela n’est possible évidemment que pour les machines compatibles EFI et reste optionnel. Pour cela, il faut utiliser un fichier kickstart avec l’option bootloader --sdboot
ou alors utiliser l’argument au niveau du noyau inst.sdboot
avant l’installation. Le noyau sera de fait installé dans la partition ESP et non plus dans le point de montage /boot
. Il devient ainsi plus simple de se passer de GRUB et de tester systemd-boot dans ce contexte, notamment pour ceux intéressés dans le développement de l’image noyau unifiée. GRUB reste le chargeur de démarrage par défaut.
La partition ESP pour les machines EFI aura une taille minimale de 500 Mio au lieu de 200 Mio. Seulement 200 Mio n’est pas suffisant, surtout dans l’optique de l’image noyau unifiée qui reste un objectif de long terme, ou même d’une cohabitation avec Windows ou la mise à jour des firmwares UEFI. Cela laissera assez de place pour ne pas bloquer ces fonctionnalités faute de place disponible. Par ailleurs cette valeur est la même que celle de Windows 10 et supérieur.
Le service régulier fwupd-refresh.timer, pour vérifier si les firmwares sont à jour, est activé par défaut pour les images IoT, CoreOS et Server. Il télécharge ainsi régulièrement les métadonnées et si une mise à jour est disponible, le message du jour affiche un message concernant cette disponibilité. Cela permet de ne pas oublier de mettre à jour les firmwares si souhaités dans des systèmes souvent sans environnement graphique permettant une telle information. La mise à jour automatique n’est pas considérée, car il faut souvent un redémarrage, une implication de l’utilisateur ou autres pour le mener à bien. L’objectif étant de favoriser la mise à jour de ces composants qui peuvent résoudre de vrais problèmes aux utilisateurs et corriger des failles de sécurité par ailleurs.
L’image avec l’environnement LXQt est disponible pour l’architecture aarch64.
Internationalisation
Le correcteur orthographique Aspell n’est plus fourni, remplacé avantageusement par hunspell ou enchant2. En effet ce composant n’est plus maintenu depuis plus de quatre ans, et de nombreuses applications passent à hunspell ce qui simplifie la maintenance du projet Fedora.
Mise à jour de IBus à la version 1.5.29. Cette version propose une meilleure intégration à l’environnement de bureau Plasma avec Wayland. Il devient possible de changer de disposition clavier depuis une icône dans la barre principale ou avec un raccourci clavier, avec les suggestions qui apparaissent près du curseur de la souris.
Alors que IBus-anthy dispose lui de la version 1.5.15. Ce composant pour améliorer la saisie en japonais a un paquet avec des métadonnées à jour pour faciliter son installation. Il permet de convertir de l’ère japonaise vers 2023 et vice versa. En cas de clavier virtuel, les suggestions sont affichées et peuvent être sélectionnées.
La police Google Noto devient celle par défaut au détriment des polices Lohit pour les langues indiennes. Cette police est mieux maintenue et supporte plus d’options pour ces langues. Les anciennes polices restent disponibles dans les dépôts.
Les polices par défaut sont gérées via des méta-paquets débutant par default-fonts. Le métapaquet default-fonts installe les méta-paquets suivants :
- default-fonts-core pour les caractères latins, les symboles mathématiques et les emojis ;
- default-fonts-cjk pour les langues chinoises, japonaises et coréennes. Il est possible d’installer les polices par défaut pour une langue spécifique par l’installation du paquet default-fonts-< code langue > (comme fr pour le français) et langpacks-fonts-< code langue > pour obtenir la police par défaut et celles recommandées pour la langue concernée.
La maintenance de tout ceci pour Fedora devient bien plus simple et c’est plus clair également pour l’utilisateur plutôt que de tirer des polices spécifiques directement par le jeu des dépendances avec des applications ou une configuration kickstart.
Le paquet man-pages-ru est supprimé, car il fait déjà partie de man-pages-l10n. Cela permet de ne plus avoir deux paquets en double pour le même travail.
Administration système
GNOME Keyring est modularisé pour être géré par systemd. Ce module de nos jours ne fournit plus que deux services à savoir une interface D-Bus secret-service et une surcouche pour ssh-agent. Maintenant ces services sont gérés indépendamment et peuvent être gérés via des services systemd ce qui rend leur gestion et celle de leurs problèmes plus simples.
Une option de cloud-init permet qu’une mise à jour de l’édition Cloud qui nécessite un redémarrage entraine un redémarrage automatique à la fin du processus. Pour cela le fichier /var/run/reboot-required doit être créée avec les bonnes options par l’utilisateur pour le permettre. L’option package_update permet l’installation automatique des mises à jour lors du premier démarrage, et l’option package_reboot_if_required contrôle la fonctionnalité ainsi décrite. Ces deux options pouvant valoir true ou false. L’application tracer et son plugin dnf nommé python3-dnf-plugin-tracer sont responsables de notifier si une mise à jour nécessite un redémarrage du système ou non pour être pleinement appliquée. Cela permet de se rapprocher du fonctionnement des systèmes Ubuntu et Debian à ce sujet, et cela permet d’améliorer l’application des mises à jour de sécurité.
Possibilité de s’identifier avec un périphérique compatible FIDO2 pour l’authentification d’un utilisateur géré via Active Directory, FreeIPA, ou LDAP. Cela est valable pour les périphériques pris en charge par la bibliothèque libfido2. Cela permet à Fedora Linux de mieux se conformer aux exigences de sécurité modernes notamment au sein du gouvernement américain qui recommande ce genre de méthodes d’authentification sans mot de passe en plus des méthodes basées sur les cartes à puce. Avoir ces deux méthodes permet notamment l’authentification multi facteurs avec plusieurs périphériques physiques.
Conversion des fichiers de configuration NetworkManager du format obsolète ifcfg vers keyfile. 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 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 et de Fedora Linux 41. Le paquet NetworkManager-initscripts-ifcfg-rh fourni ce service de migration.
Les paquets tzdata fournissant les fuseaux horaires peuvent être supprimés. Cela permet de réduire la taille des systèmes pour conteneurs où les fuseaux horaires ne sont pas forcément nécessaires. Dans ce cas le fuseau horaire reste fixé sur UTC. Les applications ayant besoin d’une telle dépendance ne l’ont que sous forme de recommandation et non plus comme une dépendance obligatoire.
Les dépôts modulaires sont arrêtés à partir de Fedora Linux 39. Cela signifie que les paquets fedora-repos-modular et fedora-repos-rawhide-modular sont supprimés, et les modules ne sont plus disponibles. Un module consistait en la possibilité de proposer plusieurs versions alternatives d’un même paquet ou ensemble de paquets, souvent entre deux versions d’un langage de programmation type PHP. Les versions de Fedora Linux antérieures restent toujours fournies le temps de leur maintenance officielle, donc un mois après Fedora Linux 40. Il y avait en effet peu de paquets qui exploitaient cette possibilité et plus personne ne maintenait l’outillage nécessaire à leur production. Les ressources du projet Fedora et des empaqueteurs seront moins dispersées par cet effort pour une solution qui n’a manifestement pas trouvé son public, sans doute à cause de l’impossibilité d’avoir plusieurs versions en parallèle d’un même module.
L’utilitaire pam_console est supprimé. Ce module PAM permet de donner des capacités supplémentaires à un utilisateur sur une console physique à l’authentification, et de les supprimer à la déconnexion de l’utilisateur notamment en changeant les permissions de certains fichiers et de certains périphériques. Mais il y avait plusieurs problèmes avec cette solution, dont l’absence de support multi utilisateurs simultanés et la persistance des droits si les étapes de déconnexions ne sont pas exécutées. Ce rôle est rempli par systemd-logind, cette fonctionnalité étant notamment utilisée pour l’accès aux CD/DVD ou disques durs externes.
La valeur du paramètre sysctl vm.max_map_count passe de 65530 à 1048576. Cela permet à un processus, en particulier les jeux fournis par WINE ou Steam, d’allouer plus de zones mémoire pour ses propres besoins. Cela devient nécessaire pour améliorer la prise en charge de ces jeux, cette valeur étant par ailleurs celle par défaut dans Windows.
Mise à jour du système de paquets RPM 4.19. Un nouvel utilitaire rpmsort est fourni pour trier les paquets par version de RPM. RPM peut prendre en charge des micro-architectures x86_64 comme architectures à part entière. Ajout des scriplets %preuntrans et %postuntrans à exécuter avant ou après la désinstallation des traductions. Et ajout de la possibilité de générer dynamiquement des fichiers specs, notamment pour générer des sous paquets de traduction.
L’outil de gestion et de configuration des machines virtuelles Vagrant est proposé à la version 2.3. Cette version propose en outre la prise en charge de VirtualBox 7.0 et les clés de chiffrement avec l’algorithme rsa-sha2.
Suppression de awscli qui fournissait la version 1 de l’interface en ligne de commande pour les services AWS. Pour accéder à ces services il faut utiliser le paquet awscli2 dorénavant, version qui est disponible depuis plus de deux ans et qui propose bien plus de fonctionnalités que la première édition notamment une expérience unifiée avec Docker et AWS Cloudshell.
Les images Fedora Linux sont proposées sur Microsoft Azure. Cela permet de proposer Fedora Linux sur plus de plateformes cloud publics, à l’instar de AWS ou GCP actuellement supportés et de devenir une option possible pour les utilisateurs de ce service sans manipulations trop lourdes pour eux.
Les images EC2 seront sans l’option standard et utiliseront par défaut l’option gp3 pour le volume de stockage. L’option standard est plus ancienne et offre de moins bonnes performances par rapport à gp2 et gp3. Par ailleurs cela pouvait être source de confusion pour les utilisateurs, car ils voyaient plusieurs alternatives pour les images à employer en plus des différences basées sur l’architecture des processeurs aarch64 et x86_64. L’utilisateur pourra toujours manuellement créer une image avec les autres options de stockage s’il le désire vraiment.
gp3 remplace dans le même temps _gp2, car il est plus flexible et coûte 20% moins cher par Gio de données à sauvegarder, car on peut augmenter les débits et nombres d’opération par seconde sans devoir allouer de l’espace supplémentaire pour cela.
Ces images EC2 seront par ailleurs soumises avec l’option uefi-preferred. L’objectif est d’utiliser l’UEFI comme méthode de démarrage si l’option est disponible sur l’instance, sinon utiliser BIOS à la place. Auparavant, Amazon ne proposait que des systèmes BIOS et la conversion des instances est progressive d’où ce choix. Cela n’est bien sûr valable que pour l’image x86_64, les instances aarch64 ne prenant en charge que l’UEFI de toute façon. L’utilisation plus vaste de l’UEFI permet d’envisager l’usage de Secure boot dans ce contexte et d’envisager une simplification à terme du processus de démarrage de Fedora Linux.
Les images EC2 décidément sont fournies avec l’option IMDSv2-only (Instance Meta-Data Store version 2). Cette option permet d’activer une protection contre quatre type d’attaques concernant les métadonnées de l’instance comme le stockage, le réseau, etc. Ainsi les métadonnées ne sont accessibles qu’à travers l’interface réseau local avec l’adresse IP 169.254.169.254 et n’est donc accessible que depuis les logiciels tournant sur cette instance.
Développement
Mise à niveau de la chaîne de compilation GNU avec GCC 13.2, Binutils 2.40, glibc 2.38 et GDB 13.2. Cette version mineure de GCC comme de GDB ne fournissent que des correctifs de bogues.
Pour binutils cette version améliore la prise en charge des extensions des architectures x86_64 et ARM. Les sections de débogue peuvent être compressées avec l’algorithme zstd et d’ailleurs le format de débogue CTF est pris en charge. Le format SFRAME est également proposé pour permettre des retours en arrière dans la pile d’exécution qui soit plus rapide. L’utilitaire objdump permet un affichage en couleur des instructions sur certaines architectures. L’éditeur de lien peut passer outre les erreurs et messages d’avertissement si nécessaire.
La nouvelle version de la bibliothèque C glibc propose la prise en charge de la syntaxe 0b pour les entiers binaires en entrées des principales fonctions proposées si le code est compilé comme du C2X. Les fonctions de la famille de printf ont un format spécial pour les types entiers définissant leur taille comme uint32_t qui peut être affiché avec l’instruction %w32x. Les fonctions strlcpy et strlcat sont ajoutées, provenant du système OpenBSD à l’origine elles permettent la copie ou la concaténation d’une chaine de caractères dans une autre avec une troncature. Et bien d’autres correctifs plus mineurs.
De même sa variante MinGW passe à GCC 13 et Binutils 2.40. qui apportent des bénéfices similaires pour ceux souhaitant compiler des binaires Windows depuis leur Fedora Linux.
Tandis que celle du projet LLVM passe à la version 17. Cette version apporte la prise en charge du FatLTO qui permet de faire cohabiter au sein d’un fichier objet le code machine avec le bitcode compatible LTO laissant à l’éditeur de lien le soin de choisir lequel employer pour le binaire. Il prend en charge les nouvelles instructions x86_64 apportées par la micro-architecture Arrow Lake et Lunar Lake d’Intel. Son compilateur emblématique clang améliore la compatibilité avec les normes des langages C++20, C++23 et C2X. Ses messages d’erreurs sont également améliorés.
Mise à jour du langage rampant Python 3.12. Cette version apporte la possibilité de définir un alias de type avec le mot clé type afin de simplifier la lecture du code, sa définition pouvant lui-même utiliser les génériques. Les expressions au sein des f-string peuvent être maintenant n’importe quelle instruction Python valide. Le module asyncio bénéfice d’amélioration de performances pouvant aller jusqu’à 75%. Et l’interpréteur est capable de donner des conseils sur comment corriger certaines erreurs, comme cela se fait avec les compilateurs C/C++ modernes. Et ce parmi d’autres changements à découvrir.
Mise à jour du langage sautillant Go 1.21. Cette version somme toute mineure apporte la prise en charge des fonctions min et max à partir d’une liste d’arguments, de même que la fonction clear pour réinitialiser ou vider les éléments d’une map ou d’une slice. L’ordre des imports des packages a été spécifié plus précisément pouvant introduire des incompatibilités avec des programmes existants. L’inférence de type dans le contexte des génériques devient plus performante en étant capable de déduire le type dans plus de cas, par ailleurs l’ensemble des mécanismes est mieux spécifié. Quelques améliorations de performances sont également de la partie en particulier pour les programmes multithreadés depuis le C vers Go. Le temps de compilation devrait être plus rapide d’environ 6%.
Les bibliothèques Go empaquetées dans Fedora Linux mais n’étant pas utilisées par un autre paquet sont supprimées. Cela représente environ 17% des paquets de bibliothèques Go. Le groupe de travail de Fedora sur Go doit maintenir 2000 paquets pour environ 35 mainteneurs, l’objectif est de réduire la charge de travail pour des paquets n’ayant pas un intérêt direct pour l’écosystème afin d’améliorer la gestion des autres paquets qui augmentent en nombre et en complexité.
Mise à jour du langage reluisant Perl 5.38. Outre la prise en charge d’Unicode 15.0, il est possible de supprimer les alertes d’obsolescence future par sous catégorie pour n’afficher que celles qui nous intéressent. Le mot clé class fait son entrée à titre expérimental qui permet de définir des données d’instances avec le mot clé field en son sein. Et bien d’autres changements plus mineurs.
Mise à jour dans l’écosystème Haskell GHC 9.4 et Stackage LTS 21. Le compilateur dispose d’un nouveau mode de profiling avec l’argument -fprof-late qui permet l’étude des performances après les optimisations du compilateur et donc avec moins d’interférence entre ces deux composants. Les performances sont significativement améliorées notamment du temps de compilation et de la mémoire consommée dans le processus. Les messages d’erreur de GHC sont mieux structurés pour permettre une meilleure intégration dans les environnements de développement.
La bibliothèque Boost est mise à jour dans sa version 1.81. Boost.URL fait son apparition en fournissant des conteneurs et des algorithmes dédiés aux URL. Tandis que dans boost::hash les performances sont améliorées alors que BOOST_HASH_NO_EXTENSION est supprimé tout comme les spécialisations de cette classe. Pour de nombreux modules la compatibilité minimale passe de C++11 à C++14.
La bibliothèque Libffi 34 va utiliser des redirections d’appels statiques et non plus dynamiques. En effet la redirection d’appel dynamique nécessite d’avoir des portions de mémoires qui sont accessibles en écriture et à l’exécution en même temps ce qui est un problème de sécurité de plus en plus détecté par SELinux et d’autres mécanismes de sécurité du système. La bibliothèque est ainsi compilée avec l’option --disable-exec-static-tramp.
L’environnement de développement Free Pascal nommé Lazarus est découpé en sous-paquets. En plus de ce changement, Lazarus bénéficie aussi de la possibilité de compiler des programmes destinés à utiliser les bibliothèques graphiques GTK3, Qt4 et Qt5 en plus de GTK2 déjà présent. Cette modularité permet de ne pas télécharger toutes les ressources associées à Lazarus s’il n’y en a pas le besoin.
Projet Fedora
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 Flatpak générés par le projet Fedora sont produits sans utiliser les modules. Les Flatpak ainsi générés existent en deux types, les runtimes qui sont en fait des paquets non modifiés de Fedora et les applications qui notamment sont déplacées de /usr vers /app. Jusqu’ici la recompilation des seconds était fondée sur la modularité qui vient d’être abandonnée (voir ci-dessus dans la section Administration système). Ici deux nouvelles cibles ont été introduites au sein du projet Fedora pour permettre cette transition. Par exemple pour Fedora Linux 39 ces cibles se nomment f39-flatpak-runtime et f39-app. La version associée au conteneur Flatpak était également basée sur celle du module correspondant, par exemple firefox-stable-3820230427145713.b1edb643. L’astuce ici est d’utiliser le nom et la version du paquet RPM avec le suffixe flatpak donnant ainsi firefox-flatpak-112.0.2-1 ce qui ne pose pas de conflits, et comme l’identification du Flatpak pour les mises à jour se fonde sur un ID unique, ici org.mozilla.Firefox, la transition est transparente.
Ce changement simplifie beaucoup la génération des Flatpak à partir des paquets RPM de Fedora. Le procédé est plus simple et il est plus facile de partager les éléments recompilés entre eux. Cependant il ne sera plus possible de tirer avantage des modules pour produire des Flatpak à partir de versions différentes de certains composants. Mais cet avantage n’a jamais été réellement exploité en cinq ans, la faute sans doute au peu d’attrait et à la complexité des modules.
Les images OCI pour fedora-toolbox deviennent bloquantes pour la sortie d’une nouvelle version de Fedora Linux, ces images devront donc être disponibles et suffisamment fiables. Cela implique également que le paquet RPM qui fournit l’utilitaire toolbox soit assez fiable pour s’en servir, sa non-stabilité pouvant devenir un composant bloquant une nouvelle version de Fedora Linux. Ce changement devient nécessaire par l’importance grandissante de cet outil dans l’écosystème, en particulier avec CoreOS, Silverblue et autres versions immuables du système où il fait partie intégrante de la manière d’utiliser le système pour un développeur. Cela permettra de réduire les quelques erreurs dans le passé où les images toolbox étaient en grand retard sur le reste des délivrables.
L’effet de bord amusant c’est que cette promotion de toolbox dans la procédure de sortie d’une nouvelle version de Fedora Linux ajoute ces contraintes sur la base du système lui-même. Jusqu’ici les contraintes étaient lâches et floues, alors que le bon fonctionnement de toolbox permet de standardiser certaines attentes autour des composants de base tels que d-bus, systemd, udev, le noyau, le réseau, Wayland, etc.
Mise à jour de createrepo_c à la version 1.0.0. Cet utilitaire, qui permet de créer des dépôts RPM, utilise par défaut l’algorithme de compression zstd au lieu de gz pour les métadonnées permettant d’avoir des fichiers plus légers et à la décompression plus rapide. Les métadonnées sous forme de base de données sqlite ne sont pas générées par défaut car cela n’est de toute façon pas exploité par DNF et consomme de fait des ressources pour rien. Les groupes dans les métadonnées ont aussi une logique plus cohérente avec le reste des métadonnées, au lieu d’avoir deux variantes injectées, une compressée et l’autre pas, la version compressée est ajoutée à la place mais cela rend de tels dépôts incompatibles avec RHEL 7 et les systèmes utilisant le vénérable gestionnaire de paquets yum. De tels utilisateurs devront utiliser l’outil modifyrepo_c à la place pour leurs dépôts personnels.
Seconde et dernière étape dans la conversion des licences des paquets vers le format SPDX. L’objectif est de finir la transition des anciens noms de licence dans les métadonnées d’un paquet RPM pour suivre la standardisation des noms introduits par le projet SPDX. La première étape initiée par Fedora Linux 38 était d’identifier les différences entre les choix historiques de Fedora et SPDX, identifier les cas limites pour adopter une politique commune notamment de transition avec une expérimentation sur quelques paquets.
Ici la transition est donc complète, cela s’est fait en améliorant le script license-fedora2spdx (fourni par le paquet license-validate) qui fait la correspondance entre un nom de licence Fedora et un nom de licence SPDX. Cette correspondance est appliquée sur l’ensemble des paquets par vague avec soumission du correctif automatique aux mainteneurs du paquet qui ont 14 jours pour réagir à la proposition afin de rectifier en cas d’erreurs. Mais beaucoup de paquets ne peuvent pas bénéficier d’une conversion automatique (par exemple si le nom de la licence était générique comme simplement BSD, laquelle licence avec ce nom exactement ?) et nécessitent une revue manuelle, d’où le fait que cette procédure ait eu lieu par vague.
Seconde réduction des extensions des options de compilation de Python. Ce travail entamé par Fedora Linux 30 sert à simplifier la compatibilité des modules Python non fournis par Fedora. En effet l’interpréteur Python conserve ses options de compilation en interne (à savoir CFLAGS, CXXFLAGS et LDFLAGS) pour être réutilisées pour la compilation de modules. Mais les options de compilation pour le paquet Python dans Fedora grossit régulièrement avec parfois des astuces non pertinentes dans ce contexte comme celle qui permet d’ajouter la dépendance à l’exécution de python3-devel avec redhat-rpm-config. Cela pose problème, car le développeur du module se retrouve avec des options non souhaitées et potentiellement problématiques, en particulier celles ayant trait aux greffons GCC et aux fichiers specs de GCC s’il utilise une chaine de compilation alternative. Ces dernières sont donc automatiquement retirées.
Les images Fedora Silverblue et Kinoite utiliseront le mode unifié de rpm-ostree. 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.
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, 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 39 ?
Si vous avez déjà Fedora Linux 38 ou 37 sur votre machine, vous pouvez faire une mise à niveau vers Fedora Linux 39. 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 39.
Aller plus loin
- Site officiel du projet Fedora (163 clics)
- Site officiel de la communauté francophone de Fedora (95 clics)
- Image Torrents officiels (51 clics)
- Procédure de mise à niveau (41 clics)
# ESP
Posté par fortytwo . Évalué à 6.
Tout d'abord, merci pour ce billet très détaillé. Pour les gens comme moi qui ne suivent pas l'actualité Fedora régulièrement, c'est un rappel salutaire à la mise à jour.
Gasp ! Mon ESP (double boot Fedora+W10) fait 100 modestes Mio, dont 44 utilisés. Dois-je m'inquiéter ?
[^] # Re: ESP
Posté par Renault (site web personnel) . Évalué à 8.
Pas forcément maintenant.
Par exemple le noyau unifié qui déplacera le noyau, l'initramfs et le chargeur de démarrage dans cette partition plutôt que dans /boot va poser problème car l'ensemble pèsera bien plus lourd que 100 Mio avec ton Windows en plus.
La question est quand un tel changement aura lieu par défaut ? Probablement pas avant des années car il y a pas mal de problèmes à résoudre avant. Et d'ici là je doute que ce soit un problème majeur dans la configuration que tu as. Et peut être qu'un mode de compatibilité existera aussi quelques temps.
Disons que si tu as l'opportunité un jour n'hésite pas à agrandir quand tu peux. Car ce jour là arrivera et probablement dans d'autres distributions aussi si tu veux mon avis.
# Lecture de vidéos
Posté par antistress (site web personnel) . Évalué à 5.
Merci !
Peut-on en savoir plus ? Quel est le logiciel concerné ?
[^] # Re: Lecture de vidéos
Posté par Renault (site web personnel) . Évalué à 10.
C'est la fonction décrite dans ce PR dans Mutter.
En lisant le détail (je m'étais basé sur le résume de GNOME à la base qui été très générique) je me dis que je pouvais apporter un éclaircissement.
En gros l'idée est qu'une application qui manipule des vidéos ou images peut utiliser une surface en YUV pour l'espace de couleur directement. Car c'est ce qui est le plus souvent utilisé dans le domaine. Du coup la conversion YUV->RGBA pour l'affichage sur l'écran est laissé au compositeur (ici mutter) qui peut l'envoyer tel quel à l'écran si c'est possible. Car les contrôleurs d'écran moderne peuvent effectuer ce genre de conversions, et si c'est le cas ça évite au CPU ou au GPU de le faire d'où le gain en performance et en énergie. Ou envoyé au GPU en second recours.
Dans ce cas ça peut bénéficier à toute application compatible Wayland techniquement, si du moins elles envoient une surface YUV au compositeur (mais en théories elles peuvent toutes le faire).
# C'est donc ça.
Posté par hugotrip . Évalué à 4.
Merci aussi, en particulier pour l'information sur :
j'avais testé la beta en VM, et j'avoue que je n'avais pas du tout compris la symbolique de ce "code morse" (je n'avais pas utilisé de bureaux multiples lors de ce test, et n'avais donc pas observé sa variabilité) : je pensais que c'était un genre de "placeholder" qui serait remplacé pour la version définitive.
Ça aurait été bien de donner l'information dans la visite guidée pour les boulets comme moi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.