Fedora 31 est sortie !

En ce mardi 29 octobre 2019, les utilisateurs et les utilisatrices du projet Fedora seront ravis d’apprendre la disponibilité de la version 31 de Fedora.

Fedora est une distribution GNU/Linux communautaire développée par le projet Fedora et sponsorisée par Red Hat (récemment acquise par IBM), qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora peut se voir comme une sorte de vitrine technologique pour cette multinationale, c’est pourquoi elle est prompte à inclure des nouveautés.

Fedora garde un rôle central dans le développement de ces nouveautés via le développement en amont. En effet, les développeurs de la distribution contribuent également directement au code d’un certain nombre de logiciels libres contenus dans la distribution, dont le noyau Linux, GNOME, NetworkManager, PackageKit, PulseAudio, X.Org, systemd, la célèbre suite de compilateurs GCC, etc. Suivez ce lien pour voir l’ensemble des contributions de Red Hat.

Sommaire

• Expérience utilisateur
  • Passage de l’environnement par défaut GNOME à la version 3.34
  • La roue tourne pour Xfce avec la version 4.14
  • Mise à jour de l’environnement de bureau DeepinDE 15.11
  • État du clavier dans Plymouth pour la saisie de mots de passe
  • Firefox utilise Wayland nativement par défaut avec GNOME
  • Utilisation de Wayland avec les applications Qt sous GNOME
  • Compression zstd dans les paquets RPM
• Gestion du matériel
  • Fedora abandonne l’architecture x86 32 bits
  • Xfce sur architecture AArch64
  • Prise en charge des modules de sécurité lors d’un amorçage UEFI sécurisé
• Internationalisation
  • Subdivision des paquets langpacks
  • Mise à jour d’IBus en version 1.5.21
  • Priorisation des polices de caractères variables Google Noto
• Administration système
  • Python 3 par défaut
  • Amélioration des politiques de sécurité
  • Passage aux cgroups 2
  • OpenSSH refuse par défaut l’authentification par mot de passe au super‑utilisateur
  • Ping accessible à tous
  • Gestionnaires de paquets
    • Le compteur RPM atteint la version 4.15
    • DNF avertit mieux qu’un dépôt est inaccessible
    • YUM 3 tire sa révérence
  • Suppression des paquets liés à 389‑console
• Développement
  • Glibc 2.30
  • Gawk passe à la branche 5.0.
  • Node.js en est à son douzième nœud
  • Sphinx passe à la version 2
  • Renommage du paquet Python 3 dédié aux tests
  • Go fonce vers la version 1.13
  • Le langage Perl reluit à la version 5.30
  • Erlang et OTP passent en version 22
  • Haskell GHC 8.6 et Stackage LTS 13
  • Mono 5.2
  • MinGW 6
  • Utilisation de LLVM LDD en alternative à GNU LD
  • GOLD a son propre paquet
• Projet Fedora
  • Publication d’une image Cloud chaque mois
  • Activation de Bodhi dans Rawhide
  • Gestion dynamique des dépendances de sources RPM
  • Nouvelles règles d’empaquetage pour les projets en Go
  • Résolution automatique des dépendances du langage R
  • Utilisation d’un gdb minimal lors de la compilation de Fedora
  • Génération de glibc32 sur infrastructures 64 bits
• La communauté francophone
  • L’association
  • La documentation
• Comment se procurer Fedora 31 ?

Expérience utilisateur

Passage de l’environnement par défaut GNOME à la version 3.34

Cette version apporte de nombreux changements :

• la création de groupes d’applications dans l’overview a été simplifiée et est plus intuitive ;
• les processus de rendus Web du navigateur Epiphany sont maintenant dans des bacs à sable pour plus de sécurité ; par ailleurs, les onglets peuvent être épinglés et le bloqueur de pub est plus performant ;
• le gestionnaire de machines virtuelles Machines peut activer ou désactiver l’accélération du rendu 3D pour chaque machine virtuelle, il accepte de démarrer un média temporaire, comme un CD autonome, pour réparer la machine virtuelle, et dispose d’une interface de création de machines virtuelles plus complète ;
• le panneau de configuration du fond d’écran a été remanié pour visualiser la configuration actuelle et permet d’ajouter facilement de nouvelles images dans la liste ;
• l’application Musique vérifie automatiquement la présence de nouveaux morceaux dans le répertoire personnel et permet de lire un album en entier sans coupure entre les morceaux ; les albums conçus ainsi peuvent être écoutés comme un tout cohérent ;
• certaines applications ont reçu une nouvelle icône pour avoir un style plus moderne.

La roue tourne pour Xfce avec la version 4.14

Après plus de quatre années de développement, cette version propose de nombreux changements. Le portage vers GTK+ 3 et GDBus est terminé, ce qui permet la prise en charge native des écrans à haute résolution (HiDPI). Cela apporte en outre :

• la gestion de la synchronisation verticale pour le rafraîchissement de l’écran ;
• les barres du bureau disposent d’un meilleur regroupement des applications dans la liste des applications ouvertes, tout comme une horloge retravaillée et la possibilité d’avoir des tailles d’icônes différentes entre les différentes barres ;
• la prise en charge des différents profils de couleurs pour permettre un calibrage des couleurs entre l’écran et différents périphériques, comme une imprimante ;
• la configuration du multi‐écran peut être sauvegardée et restaurée, et est spécialement conçue pour ceux qui ont un ordinateur portable avec un dock ;
• le navigateur de fichiers Thunar dispose d’une nouvelle barre d’adresse ;
• un nouveau thème et un mode « ne pas déranger » pour désactiver temporairement les notifications sont aussi de la partie ;
• et tant d’autres.

Mise à jour de l’environnement de bureau DeepinDE 15.11

Depuis la version 15.9 disponible dans Fedora 30, les améliorations sont :

• une moindre consommation mémoire et plus de performances pour le gestionnaire de fenêtres ;
• les fichiers du bureau peuvent être automatiquement regroupés par type dans des répertoires comme Musiques ou Vidéos ;
• le fond d’écran peut être une collection d’images affichées les unes après les autres ;
• les sons système peuvent être activés ou désactivés individuellement ;
• l’icône de charge de batterie peut révéler au survol la capacité et l’autonomie restante ;
• l’application de lecture vidéo accepte le glisser‐déposer d’un fichier de sous‑titres pour les afficher ;
• le navigateur de fichiers peut graver des CD et DVD ;
• et beaucoup d’autres corrections.

État du clavier dans Plymouth pour la saisie de mots de passe

Plymouth indique au démarrage des informations sur l’état du clavier lors de la saisie du mot de passe pour déchiffrer les partitions. Si vous chiffrez vos partitions pour améliorer la sécurité de vos données, vous aurez constaté qu’il y a un mot de passe à saisir au démarrage de la machine pour accéder à son contenu. Plymouth, qui récupère ce mot de passe, affiche maintenant la disposition clavier utilisée et si le verrouillage majuscule est actuellement actif. Cela permet à l’utilisateur qui n’a pas de possibilité de vérifier comment son clavier est configuré d’avoir cette information lors de la saisie.

Firefox utilise Wayland nativement par défaut avec GNOME

L’activation de Wayland dans Firefox permet d’améliorer la gestion des ressources dans un tel cas, XWayland n’étant plus nécessaire par défaut. Firefox devrait bénéficier d’une expérience plus fluide et plus cohérente, en particulier pour les écrans à haute densité de pixels qui seront correctement pris en charge. Le paquet firefox-x11 reste à disposition pour utiliser Firefox avec X11 comme avant.

Utilisation de Wayland avec les applications Qt sous GNOME

Les applications Qt utiliseront de manière analogue Wayland lors d’une session GNOME sous Wayland. Les mêmes bénéfices que pour Firefox sont à attendre. En réalité, GNOME était le seul bureau où les applications Qt se comportaient ainsi, car le module Qt Wayland n’était pas activé pour une telle session. En effet, le gestionnaire de fenêtres de GNOME, Mutter, demande aux applications qu’elles gèrent elles‑mêmes la decoration de leurs fenêtres (Client‑Side Decorations), ce qui n’était pas possible avec Qt jusqu’ici. Les décorations de fenêtres proviennent du programme QGnomePlatform.

Compression zstd dans les paquets RPM

Les paquets RPM utilisent le format de compression zstd au lieu de xz. Le temps de décompression est plus rapide d’un facteur trois ou quatre pour le paquet Firefox, par exemple. La taille d’un paquet sera aussi sensiblement plus faible. En contrepartie, la génération d’un paquet est légèrement plus longue. Les opérations d’installation ou de mise à jour des paquets seront plus rapides et le projet Fedora économisera également un peu de bande passante pour fournir ces paquets aux utilisateurs.

Gestion du matériel

Fedora abandonne l’architecture x86 32 bits

Le noyau Linux i686 n’est plus généré et les dépôts associés sont également supprimés. De fait, il n’y aura plus d’images amorçables de Fedora pour cette architecture, ni de mise à niveau possible depuis Fedora 30 pour ces installations. Des paquets i686 peuvent subsister dans les dépôts à destination des utilisateurs ayant l’architecture x86-64 uniquement.

Cela résulte d’un processus amorcé depuis Fedora 27 où cette architecture était une architecture dite secondaire, c’est‑à‑dire avec une maintenance minimale et qui ne pouvait pas bloquer la procédure de sortie d’une nouvelle version de Fedora. Cette architecture qui était finalement assez peu utilisée ces derniers temps, avec environ 1 % des utilisateurs, souffrait de nombreux bogues, souvent découverts et corrigés tardivement faute de testeurs et de développeurs pour identifier et corriger ces problèmes.

Le projet espère ainsi libérer des ressources matérielles, en espace disque et bande passante, mais aussi humaines, pour se concentrer sur les autres architecture plus émergentes comme AArch64. Les utilisateurs concernés sont invités, soit à utiliser une image x86-64, si leur matériel le leur permet, soit à envisager de changer de distribution d’ici la fin du support de Fedora 30.

Xfce sur architecture AArch64

Le spin Xfce de Fedora dispose d’une image pour l’architecture AArch64. L’objectif est de fournir par défaut un environnement de bureau plus léger ne nécessitant pas l’accélération matérielle. L’usage de Fedora pour les ordinateurs monocartes exploitant cette architecture, et qui ont souvent une configuration matérielle moins puissante, s’en trouvera facilité.

Prise en charge des modules de sécurité lors d’un amorçage UEFI sécurisé

Sur les machines avec la fonctionnalité Secure Boot de l’UEFI activée, GRUB inclut maintenant les modules de sécurité. Les modules concernés sont verify, cryptodisk et luks. En effet, Secure Boot, par conception, ne permet pas à GRUB de charger des modules externes, ce qui était paradoxal car les modules de chiffrement des partitions n’étaient pas disponibles pour ces utilisateurs.

Internationalisation

Subdivision des paquets langpacks

Les paquets langpacks sont subdivisés avec une partie langpacks-core qui ne propose que la police par défaut et la localisation (locale) correspondante. Les polices additionnelles, tout comme les traductions complètes, comme celle de LibreOffice, nécessitent l’installation du paquet langpack correspondant. L’utilisateur a donc plus de flexibilité à ce niveau pour bénéficier d’un prise en charge minimale d’une langue.

Mise à jour d’IBus en version 1.5.21

La version 1.5.21 d’IBus repousse les raccourcis de composition de 7 touches à 255 touches. De plus, IBus permet maintenant l’écriture de caractères représentés par quatre octets au lieu de deux octets jusqu’ici. Il rejoint ainsi X11 en termes de possibilités de saisie.

Priorisation des polices de caractères variables Google Noto

Les polices Google Noto variables auront maintenant la priorité sur les polices non variables du même fournisseur. Une police variable est un fichier de police de caractères qui contient le dessin de base des caractères avec les éléments permettant de générer des variations de ces dessins, comme le gras ou l’italique. Alors qu’une police non variable contient un fichier complet par variation de ce type. Le rapport d’espace disque nécessaire varie d’un facteur 4 à 10 en faveur de la police variable, d’où ce choix.

Administration système

Python 3 par défaut

Le binaire /usr/bin/python fait dorénavant référence à Python 3 et non plus à Python 2. En effet, Python 2 ne sera plus supporté par le projet officiel en janvier 2020. Le projet Fedora respecte donc la PEP 394 pour entamer cette transition. En cas de problèmes, vous pouvez créer le lien symbolique de ~/.local/bin/python, pour un utilisateur, ou de /usr/local/bin/python, pour le système entier, vers /usr/bin/python2 afin de restaurer le comportement historique.

Le nom des paquets suit également ce nouveau schéma, le paquet python-requests installera par exemple la version compatible Python 3 de ce paquet. Il faudra nommer spécifiquement python2-requests pour préciser le paquet compatible avec Python 2 de ce module.

De plus, il y a une suppression massive de paquets Python 2 pour ne garder essentiellement que les derniers projets non convertis à Python 3 aujourd’hui. Seuls les paquets nécessitant Python 2 qui n’ont pas une version Python 3, ou qui sont une dépendance à de tels paquets, sont conservés. Cela réduit la tâche de maintenance nécessaire après janvier 2020 et permet d’amorcer la transition en plusieurs étapes.

Les mainteneurs du projet Fedora continueront à maintenir Python 2 dans Fedora 30 et 31 jusqu’à leurs fins de vie respectives, c’est‑à‑dire vers juin et décembre 2020. Python 2 sera, en revanche, totalement supprimé pour Fedora 32. Cette décision permet de garder une compatibilité fonctionnelle importante au sein d’une même version de Fedora.

Amélioration des politiques de sécurité

La fonction des politiques de sécurité offre maintenant la possibilité aux administrateurs de personnaliser les règles comme le choix des protocoles et les algorithmes de sécurité utilisables ou non sur le système. Cette fonctionnalité, introduite peu à peu dans Fedora ces dernières années, permet aux administrateurs de configurer de manière globale et centralisée la sécurité du système. Avec ce changement, il est possible de bannir globalement l’utilisation des fonctions de hachage SHA1 et MD5 ou d’exiger au minimum TLS 1.3.

Passage aux cgroups 2

Le noyau propose les cgroups 2 au lieu de la version 1 utilisés jusqu’alors. Cette version 2 est disponible dans le noyau de manière stable depuis près de trois ans déjà, mais elle n’était pas assez éprouvée par l’espace utilisateur. Elle corrige les défauts de jeunesse de cgroups v1 en éliminant des comportements étranges, comme des fils d’exécution d’un processus qui sont dans des cgroups différents, a une API plus claire et propre, et une hiérarchie unifiée.

Les projets systemd ou les outils de conteneurisation comme Docker ou Podman sont particulièrement concernés. D’ailleurs, pour Docker, il est nécessaire de passer l’argument systemd.unified_cgroup_hierarchy=0 au noyau pour qu’il continue de fonctionner.

OpenSSH refuse par défaut l’authentification par mot de passe au super‑utilisateur

OpenSSH refuse par défaut les identifications par mot de passe pour le compte super‑utilisateur. Cela ne fait que suivre la configuration par défaut du projet officiel depuis 2015 à ce sujet. La sécurité s’en retrouve renforcée.

Ping accessible à tous

Tous les groupes utilisateurs ont la possibilité native de faire des ping sur le réseau sans binaire setuid. Cela est surtout à destination des environnements avec conteneur ou Fedora Silverblue. Ce changement affecte à la configuration sysctl net.ipv4.ping_group_range la valeur maximale pour que tous les groupes utilisateurs y aient le droit. Les capacités CAP_NET_ADMIN et CAP_NET_RAW ne sont pas nécessaires non plus en recourant aux sockets ICMP Echo au lieu des sockets raw. Ils nécessitent en effet moins de droits que le second, car il ne permet pas d’usage abusif ou ne présente pas un risque de sécurité.

Gestionnaires de paquets

Le compteur RPM atteint la version 4.15

Cette version 4.15 du gestionnaire de paquets RPM apporte un meilleur parallélisme pour les tâches de compilation. De nombreux rapports d’erreur sont plus clairs, et de nombreuses macros ont été ajoutées comme %elif, %elifos et %elifarch, ce qui devrait simplifier la vie des empaqueteurs.

DNF avertit mieux qu’un dépôt est inaccessible

DNF émettra une erreur par défaut si un dépôt est inaccessible, au lieu d’émettre seulement un avertissement. Cela est surtout à destination des dépôts tiers qui n’activaient pas forcément cette option dans leur propre configuration. C’est l’option skip_if_unavailable qui a la valeur false par défaut dorénavant et concerne aussi libdnf ainsi que, de fait, les outils tiers qui s’en servent.

L’objectif est de rendre plus visible le fait qu’un dépôt n’est pas accessible pour l’utilisateur. L’avertissement était souvent noyé dans une grande quantité d’informations pour l’utilisateur. En cas de mise à jour, avec un dépôt mal configuré ou d’un problème quelconque, l’utilisateur pouvait croire que ses applications étaient à jour, alors qu’en réalité il devait résoudre ou signaler un problème pour les obtenir.

YUM 3 tire sa révérence

YUM cède sa place à DNF, seuls des liens symboliques vers DNF sont maintenus. Son API n’est également plus accessible.

Suppression des paquets liés à 389‑console

Les paquets liés à 389-console sont retirés au profit d’une nouvelle interface Web via Cockpit. Cela concerne les paquets 389-console, 389-ds-console, 389-admin-console, 389-dsgw, 389-admin et 389-adminutil. Ces interfaces écrites en Java n’étaient en effet plus maintenues depuis quelque temps.

Développement

Glibc 2.30

Mise à jour de la bibliothèque C glibc vers la version 2.30. Cette version propose la prise en charge d’Unicode 12.1.0, les appels système getdents64, gettid et tgkill ont été ajoutés, et elle propose aussi, depuis une révision POSIX, des fonctions d’attente de pthread basées sur une horloge monotone ou réelle, ce qui complète les fonctions existantes basées sur un delta temporel exploitant une structure timespec. Et, bien sûr, de nombreuses autres corrections.

Gawk passe à la branche 5.0.

La version 5.0 de GNU Awk corrige essentiellement de nombreux bogues. Son moteur d’expressions rationnelles récupère celui de GNULIB, ce qui met fin à une grosse activité de maintenance. Mais surtout, il prend en charge les espaces de noms. L’espace de noms par défaut étant awk. La compatibilité ascendante n’est pas totalement garantie avec cette mise à jour.

Node.js en est à son douzième nœud

Depuis la version 10, Node.js gère le protocole de sécurité TLS 1.3, alors que les versions 1.1 et 1.0 sont désactivés par défaut. Le nouvel analyseur HTTP expérimental llhttp a été ajouté. Et, bien entendu, de nombreux autres correctifs plus mineurs.

Sphinx passe à la version 2

Le générateur de documentation Sphinx passe à la version 2. La conséquence principale est l’abandon de la prise en charge de Python 2 par le projet. La sortie par défaut est maintenant en HTML 5.

Renommage du paquet Python 3 dédié aux tests

Les tests Python passent du paquet python3-libs au paquet python3-test. Cela permet de résoudre quelques bogues liés à ce choix qui n’était pas non plus très cohérent.

Go fonce vers la version 1.13

Le langage Go passe à la version 1.13. Cette version apporte de nouvelles syntaxes pour exprimer des nombres en binaire, octal, hexadécimal flottant ou avec des séparateurs de milliers, afin de rendre le code plus clair et proche de ce qu’on retrouve dans d’autres langages comme Python ou C++. Quelques améliorations de performances aussi autour de l’instruction defer et la mémoire qui est libérée plus rapidement quand l’application n’en a plus besoin. Il gère aussi TLS 1.3 par défaut.

Le langage Perl reluit à la version 5.30

Perl 5.30 installe les modules CPAN dans le dossier lié à une version de Perl comme /usr/local/{share,lib*}/perl5/5.30 au lieu de /usr/local/{share,lib*}/perl5. L’objectif étant d’éviter de casser la compatibilité des modules à cause d’une mise à niveau de Perl. Mais les utilisateurs devront procéder à une réinstallation des modules. De plus, Perl 5.30 prend en charge Unicode 12.1 et améliore la vitesse de conversion vers UTF-8. Les expressions rationnelles tiennent compte partiellement d’Unicode, par exemple « [0-5] » peut correspondre évidemment aux chiffres de 0 à 5 dans les langues latines, mais aussi à leurs équivalents dans d’autres alphabets.

Erlang et OTP passent en version 22

Le langage Erlang et OTP passent à la version 22. Le compilateur est plus rapide et efficace, notamment sur les opérations sur les chaînes de caractères. Il met à disposition une nouvelle API bas niveau pour les sockets à titre expérimental. Les opérations de sécurité SSL et TLS sont également plus rapides. En termes d’optimisation, il prend en charge le Erlang Distribution Protocol, qui scinde les gros paquets en paquets plus petits pour éviter les blocages. Fedora a spécifiquement travaillé à la migration des journaux des applications Erlang vers journald et à l’utilisation de D-Bus, grâce à erlang-dbus, pour avoir un système toujours plus cohérent.

Haskell GHC 8.6 et Stackage LTS 13

Le compilateur Haskell GHC et Stackage LTS passent respectivement à la version 8.6 et 13. Cette évolution du langage bénéficie du QuantifiedConstraints pour exprimer plus finement des contraintes sur un type. La réduction des opérations arithmétiques devrait être plus efficace. Les nombres entiers acceptent le caractère de soulignement (underscore) comme séparateur de milliers. Et beaucoup de corrections encore.

Mono 5.2

La pile .Net libre Mono bénéficie de la version 5.20. Cette mise à jour comporte principalement l’ajout de l’interface Security Support Provider Interface pour établir une connexion à une base de données SQL. Et le reste est essentiellement de la correction de bogues.

MinGW 6

L’environnement et la chaîne de compilation MinGW passent la sixième. MinGW, qui permet de compiler des binaires pour Windows depuis GNU/Linux, gère maintenant la branche WinRT et notamment les derniers ajouts liés à la prise en charge de l’architecture ARM64. Il tire parti aussi des dernières évolutions de WINE dans la compatibilité avec l’interface COM de Windows. L’environnement d’exécution C est aussi complété pour une meilleure compatibilité.

Utilisation de LLVM LDD en alternative à GNU LD

Le projet Fedora propose une configuration alternative de l’éditeur de lien, pour passer aisément de celui du projet GNU LD à celui de LLVM LDD et vice versa sans changer l’environnement de développement. Cela permet de contourner facilement les environnements de développement qui font appel directement à LD car il est le plus répandu et disponible par défaut. Pour passer à LLD, il suffit d’appeler la commande suivante :

$ update-alternatives --set ld /usr/bin/lld

Et pour revenir en arrière :

$ update-alternatives --set ld /usr/bin/ld.bfd

/usr/bin/ld est donc maintenant un lien symbolique.

GOLD a son propre paquet

L’éditeur de lien GOLD de binutils, développé par Google mais maintenant maintenu par GNU, a son propre paquet, binutils-gold, pour facilement s’en séparer si la maintenance s’arrête. Le projet n’étant plus développé activement.

Projet Fedora

Publication d’une image Cloud chaque mois

L’image Cloud de Fedora bénéficiera d’une nouvelle image chaque mois. L’objectif est de favoriser la mise à jour des installations existantes, mais surtout que les nouvelles puissent tirer bénéfice des paquets les plus récents dès l’installation.

Activation de Bodhi dans Rawhide

Dans la continuité de rendre Rawhide plus stable et d’améliorer l’assurance qualité, Bodhi est activé pour la branche Rawhide. Rawhide est la branche de développement de Fedora et reçoit beaucoup de mises à jour au fil du temps, pour relativement peu de testeurs. Son fonctionnement à part justifiait aussi le peu de ressources d’assurance qualité qui lui étaient dédiées.

Ce changement signifie qu’un paquet peut suivre le même processus pour une mise à jour sur Rawhide que pour une version stable. C’est‑à‑dire qu’un paquet soumis, sauf exceptions, attend quelques jours dans des dépôts de tests. Si la mise à jour n’a pas reçu d’avis négatifs provenant d’utilisateurs (qui est appelé aussi le karma) ou si cela fait trop longtemps qu’elle attend, soit environ deux semaines, la mise à jour sera diffusée plus largement. Mais surtout, la mise à jour n’est poussée que si les tests automatiques ont réussi.

Gestion dynamique des dépendances de sources RPM

Les sources RPM peuvent avoir des dépendances lors de la compilation qui sont gérées dynamiquement. En effet, de plus en plus de langages comme Rust, Node.js, Ruby, Python, Haskell ou Go gèrent eux‑mêmes les dépendances pour compiler un projet. Ainsi, pour un projet donné, l’empaqueteur n’a plus à recopier les dépendances que le projet a déjà lui‑même renseignées à la main. Ce qui devrait réduire le risque d’erreurs et faciliter le travail du mainteneur.

Nouvelles règles d’empaquetage pour les projets en Go

De nouvelles règles d’empaquetage pour les projets utilisant Go ont été édictées. Jusqu’ici, les règles d’empaquetage autour des projets employant Go étaient un brouillon jamais formellement adopté. L’arrivée de Go 1.13 et du concept de modules par défaut est le bon moment pour aller plus loin. Ainsi, ils disposent maintenant de la macro go-rpm-macros pour simplifier et uniformiser la description des paquets. Ils attendent une maintenance simplifiée et moins d’erreurs dans la gestion des 775 paquets concernés.

Résolution automatique des dépendances du langage R

Les dépendances autour du langage R lors de l’exécution peuvent maintenant être résolues automatiquement. En effet, les modules R décrivent les dépendances dans les méta‑données mais cette information n’était pas jusqu’ici exploitée. Maintenant, cette information est collectée et assignée automatiquement dans le source RPM du paquet. Cela simplifie la charge de travail et réduit les erreurs de maintenance.

Utilisation d’un gdb minimal lors de la compilation de Fedora

L’environnement de compilation de Fedora, le buildroot, utilise un gdb minimal pour gagner en efficience. Cet environnement de compilation est utilisé pour la génération de chaque nouveau paquet, la moindre optimisation est donc bonne à prendre car il est sollicité un très grand nombre de fois. Il ne dispose plus de la gestion de la coloration syntaxique, XML ou de Python qui ne sont pas nécessaires dans ce contexte. Cela permet du coup de ne plus avoir besoin de Python 3 dans buildroot. Il nécessite maintenant 54 Mio à télécharger, au lieu de 77 Mio, et passe de 339 Mio à 249 Mio en espace disque. Cette version allégée est disponible via le paquet gdb-minimal, qui installe le binaire /usr/bin/gdb.minimal pour ceux qui le souhaitent.

Génération de glibc32 sur infrastructures 64 bits

Le paquet glibc32 nécessaire pour le buildroot de Fedora bénéficie d’une amélioration de sa compilation pour être plus maintenable et garantir le respect de la licence LGPL. En effet, les architectures 64 bits x86-64, PPC64 et s390x sont compatibles avec leurs architectures de base respectives qui les précèdent, à savoir i686, PPC et s390. Donc, un logiciel compilé pour les secondes peut fonctionner sur les premières architectures. Cela permet donc de faire ce qui est nommé du « multilib ». Une version de Fedora x86-64 native peut installer des paquets destinés à la base pour i686 pour des raisons de compatibilité.

Cependant, glibc est une bibliothèque centrale et est nécessaire pour beaucoup de composants de base, dont GCC. Or, Fedora ne permet pas de compiler dans son infrastructure un paquet i686 pour du x86-64, par exemple. Donc, globalement, l’astuce employée jusqu’ici était de récupérer les paquets générés pour l’image i686 directement pour x86-64. Mais, pour PPC64 et s390x, leurs équivalents 32 bits ne sont plus du tout générés, ce qui pose problème car une copie ancienne de glibc32 est utilisée et Fedora n’est plus capable de la compiler à nouveau. Ce qui semble problématique au regard de la LGPL du projet.

Désormais, une exception a été incluse dans l’infrastructure pour générer glibc et glibc32 ensemble, en partant donc du même code source.

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 régulièrement des évènements promotionnels, comme les Rencontres Fedora, et participe à l’ensemble des évènements majeurs concernant le Libre, principalement à travers la France.

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 hebdomadaires chaque lundi soir à 20 h 30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).

Vous pouvez aussi nous rencontrer lors du prochain Paris OpenSource Summit les 10 et 11 décembre (ce sont un mardi et un mercredi) aux Docks de Paris à Aubervilliers. Un stand sera installé pour présenter Fedora, obtenir vos retours et répondre à vos questions.

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, José Fournier et les autres contributeurs et relecteurs pour leurs contributions.

L’équipe se réunit tous les lundis soirs après 21 h (heure de Paris) sur IRC (canal #fedora-doc-fr sur Freenode) pour faire progresser la documentation par un travail collaboratif. Le reste de la semaine cela se passe sur les listes de diffusion.

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

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

Aller plus loin

• Site officiel du projet Fedora (130 clics)
• Site de la communauté francophone de Fedora (56 clics)
• Notes de version de Fedora 31 (43 clics)
• Images Torrents officielles (41 clics)
• Procédure de mise à niveau (38 clics)