Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : Fedora

Résultats des élections de Fedora 12/21

Charles-Antoine Couret

Le scrutin est comme toujours un vote par valeurs. Nous pouvons attribuer à chaque candidat un certain nombre de points, dont la valeur maximale est celui du nombre de candidat, et le minimum 0. Cela permet de montrer l'approbation à un candidat et la désapprobation d'un autre sans ambiguïté. Rien n'empêchant de voter pour deux candidats avec la même valeur.

Les résultats pour le Conseil sont (seul le premier est élu) :

  # votes |  noms
  - --------+----------------------
570     Tom Callaway
  - --------+----------------------
370     Till Maas
349     David Duncan

À titre indicatif le score maximal possible était de 252 * 3 votes soit 756 votes.

Les résultats pour le FESCo sont (seuls les quatre premiers sont élus) :

  # votes |  noms
- --------+----------------------
1334    Miro Hrončok
1205    Kevin Fenzi
1052    Zbigniew Jędrzejewski-Szmek
979     Fabio Valentini
862     David Cantrell
- --------+----------------------
739     Tom Stellard
290     Ahmed Almeleh

À titre indicatif le score maximal possible était de 260 * 7 soit 1820.

Les résultats pour le Mindshare sont donc (seul le premier est élu):

     # votes |  noms
     - --------+----------------------
427     Till Maas
     - --------+----------------------
317     Stephen Snow
285     Fernando F. Mancera

À titre indicatif le score maximal possible était de 219 * 3 soit 657.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin avec un réel enjeu était proche aux alentours de 260-210 votants ce qui est un peu en au dessus de l'édition précédente. Les scores sont aussi plutôt éparpillés.

Bravo aux participants et aux élus et le meilleur pour le projet Fedora.

Fedora 34 vs Fedora 33 : comparaison des performances pour les versions 64 bits

Patrice Kadionik

Salut.

Voici les résultats comparatifs de Fedora 34 vs Fedora 33.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 34 version 64 bits avec le noyau Fedora 5.11.12-300.fc34.x86_64.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 34 et exécuté sous Fedora 34 (5.11.12-300.fc34.x86_644).
  • 10 séries de tests avec UnixBench compilé sous Fedora 33 et exécuté sous Fedora 33 (5.9.14-200.fc33.x86_64).
Voici les résultats obtenus :

Fedora 34 version 64 bits :

Série 1 : 673.3
Série 2 : 688.6
Série 3 : 658.4
Série 4 : 666.6
Série 5 : 678.3
Série 6 : 672.8
Série 7 : 685.8
Série 8 : 681.7
Série 9 : 679.7
Série 10 : 677.8

Moyenne : 676.3

Fedora 33 version 64 bits :

Voici pour rappel les résultats obtenus avec Fedora 33 :
Série 1 : 695.5
Série 2 : 699.9
Série 3 : 714.6
Série 4 : 711.5
Série 5 : 714.1
Série 6 : 605.6
Série 7 : 683.1
Série 8 : 695.9
Série 9 : 707.2
Série 10 : 697.6

Moyenne : 692,5

Résultats :

Pour Fedora 34, on obtient un indice moyen de 676.3 pour UnixBench.
Pour Fedora 33, j'avais obtenu un indice moyen de 692,5 pour UnixBench.


On a donc une petite baisse de 2,3 % de Fedora 34 64 bits par rapport à Fedora 33 64 bits :

perfs_fedora_F34.png

Conclusion :

Au moment de ces tests, le noyau Fedora 34 (basé sur le noyau vanilla 5.11.12) est un peu moins performant de près de 2,3 % que le noyau Fedora 33 (basé sur le noyau vanilla 5.9.14). On retrouve la fluctuation habituelle peu significative par rapport aux précédents tests.

++

Fin de maintenance de Fedora 33

Charles-Antoine Couret

C'est en ce mardi 30 novembre 2021 que la maintenance de Fedora 33 prend fin.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 35, la version n-2 (donc Fedora 33) n'est plus maintenue.

Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 33 et antérieurs d'effectuer la mise à niveau vers Fedora 35 ou 34.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 34 ou 35. N'hésitez pas à lancer la mise à niveau par ce biais.

12/21 Élections pour le Conseil, FESCo et Mindshare pendant deux semaines

Charles-Antoine Couret

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au vendredi 9 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Par ailleurs, comme pour le choix des fonds d'écran additionnel, vous pouvez récupérer un badge si vous cliquez sur un lien depuis l'interface après avoir participé à un vote.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège. Ici 5 places sont à remplacer.

Mindshare

Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

  • La communication entre les équipes, notamment entre la technique et le marketing ;
  • Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
  • Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
  • Gestion de l'équipe marketing.

Il y a 9 membres pour gérer ce comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.

Revue de presse de Fedora 35

Charles-Antoine Couret

Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora 35 !

Bien entendu je passe sous silence mon blog et le forum de fedora-fr.

Sites web d'actualité

Soit 4 sites sur les 25 contactés.

Blogs, sites persos ou sites non contactés

Soit 6 sites.

Bilan

Le nombre de sites parlant de Fedora 35 est en légère augmentation, en particulier auprès des non sollicités.

La semaine de sa sortie, nous avons eu globalement une augmentation de visites par rapport à la semaine d'avant de cet ordre là :

  • Forums : hausse de 4,6% (environ 210 visites en plus)
  • Documentation : hausse d'environ 1,9% (soit environ 100 visites en plus)
  • Le site Fedora-fr : hausse de 30% (soit 100 visites en plus)
  • Borsalinux-fr : hausse de 220% (soit 24 visites en plus)

Si vous avez connaissance d'un autre lien, n'hésitez pas à partager !

Rendez-vous pour Fedora 36.

Sortie de Fedora Linux 35

Charles-Antoine Couret

En ce mardi 2 novembre, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 35.

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, cest 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 dun certain nombre de logiciels libres contenus dans la distribution, dont le noyau Linux, GNOME, NetworkManager, PackageKit, PulseAudio, Wayland, systemd, la célèbre suite de compilateurs GCC, etc. Cliquez ici pour voir lensemble des contributions de Red Hat.

Cela a été aussi abordé dans une série d'articles ici, et par ici encore.

GNOME-Bureau.png, oct. 2021

Expérience utilisateur

Passage à GNOME 41.

Le centre de contrôle est doté de nouvelles options.

Tout d'abord dans le menu Énergie, il y a la possibilité de choisir un mode de performance de l'ordinateur. Option souvent proposée dans d'autres systèmes comme Windows, il est possible de choisir entre le mode performance, un mode équilibré ou un mode d'économie d'énergie. Ces options dépendent du matériel de votre machine, certaines options peuvent être absentes. L'objectif est que l'utilisateur puisse adapter l'usage de sa machine en fonction de ses besoins du moment. Pour faciliter cela, il est possible de changer de mode via le menu de la barre principale de GNOME Shell. Et quand la batterie est faible, le mode économie d'énergie est utilisée automatiquement.

Par ailleurs, un nouveau menu Multi-tâches fait son apparition. Il permet de définir si la souris au coin supérieur gauche affiche ou non la vue d'ensemble des activités. Une autre option pour que déplacer une fenêtre vers un coin de l'écran permet d'afficher l'application sur la moitié de l'écran correspondant. Le comportement des espaces de travail, grandement remaniés avec GNOME 40, peut être configuré : nombre fixe ou dynamiques des bureaux virtuels, si ces espaces de travail sont sur l'écran principal uniquement ou tous les écrans, et encore si le comportement de Alt-Tab affiche toutes les applications ou seulement celles de l'espace de travail actuel.

Enfin le centre de contrôle expose des informations pour les connexions mobiles de votre machine. Cela permet de choisir si vous préférez une connexion 2G, 3G ou 4G, s'il y a une limite de données, l'activation ou non de l'itinérance des données et le code pin de la carte SIM. Ces options ne sont affichées que si la machine dispose d'une telle fonctionnalité.

La boutique Logiciels a été rafraîchie. Les captures d'écrans sont plus grosses, il y a plus de catégories pour les applications ou encore une page d'accueil présentant plus d'informations. La présentation des éléments pour une application est également plus visuelle et claire. Il gagne également en vitesse et en fiabilité.

Une nouvelle application Connexions permet de gérer les connexions graphiques distantes via les protocoles RDP ou VNC. Cela permet d'éviter de recourir à Machines pour cet usage, il est ainsi dédié à la virtualisation.

La calculatrice a été retouchée avec un mode clavier qui facilite les conversions d'unités et efface le clavier visuel. Tandis que le clavier visuel dans les autres modes a été redessiné.

De manière générale GNOME bénéficie d'améliorations de performances, en particulier en réduisant la latence entre une entrée clavier ou souris, et une plus grande fiabilité des gestes multi touches.

En lien avec la nouvelle fonctionnalité de GNOME concernant l'énergie, Fedora Linux installe par défaut le paquet power-profiles-daemon pour contrôler via DBus la politique énergétique du système entre performance, équilibré ou économie d'énergie. La disponibilité des modes dépend de votre matériel. Il est possible de personnaliser des actions pour par exemple désactiver la recharge rapide par USB des périphériques quand l'ordinateur portable est en mode économie d'énergie.

Les applications gourmandes en ressources comme des jeux vidéo ou de rendus 3D peuvent ainsi modifier le mode de la machine hôte pour garantir son bon fonctionnement.

GNOME Logiciels et GNOME Initial Setup proposent une option à l'utilisateur pour activer des dépôts tiers. Le paquet fedora-third-party offre un script du même nom pour configurer ou connaître lactivation ou non de ces dépôts. L'ensemble est sauvegardé dans le fichier /etc/fedora-third-party.conf. Ce mécanisme permet de facilement gérer ce choix pour Flatpak, dnf et GNOME Logiciels.

GNOME-Calculatrice.png, oct. 2021

Ajout d'un dépôt tiers nommé fedora-flathub-filter qui expose des applications Flatpak provenant de Flathub sélectionnées par Fedora. Il exploite la fonctionnalité décrite au paragraphe précédent. L'installation usuelle de Flathub reste nécessaire pour accéder à l'ensemble de ses applications. Ce dispositif permet d'afficher facilement aux utilisateurs les applications Flatpak provenant de Flathub dans Fedora, en évitant la redondance avec les paquets RPM et en retirant aussi les logiciels posant des problèmes légaux pour le projet Fedora.

WirePlumber va gérer les sessions Pipewire pour l'audio dorénavant plutôt que ce que Pipewire utilise en interne. En effet, Pipewire a besoin d'un gestionnaire de sessions pour les opérations suivantes :

  • créer et configurer les périphériques multimédia détectés par le système ;
  • configurer les applications et le routage des flux audio et vidéo vers les périphériques ou différents filtres ;
  • garder en mémoire les périphériques par défaut et leurs différents volumes ;
  • modifier les flux audio et vidéo en cas de connexion ou déconnexion d'un périphérique.

Wireplumber a plus d'options que Pipewire à ce sujet, utilise les GObjects ce qui permet un une communication avec différents langages de programmation, et peut être configuré avec des scripts LUA.

Le système Fedora Kinoite devient une variante officielle. C'est l'équivalent de Fedora Silverblue avec KDE Plasma comme environnement graphique par défaut. C'est donc un système immuable (en lecture seule) très minimaliste, qui doit utiliser des applications via Fedora toolbox ou les Flatpaks.

Gestion du matériel

L'image Fedora Cloud prend en charge le mode hybride BIOS et UEFI pour le démarrage de la machine. On passe donc d'un partitionnement par défaut avec une partition unique et un MBR implicite à ce schéma :

1-BIOS boot

2-EFI System (FAT32)

3-/boot (ext4)

4-/ (btrfs)

Ainsi, le démarrage fonctionnera peu importe si la machine fonctionne avec un BIOS classique ou un UEFI.

Cela fait suite au travail entrepris pour Fedora Linux 34 d'unifier la configuration de GRUB. Cela permet d'unifier la gestion du démarrage dans Fedora, de suivre d'ailleurs celle d'OpenSUSE et de CentOS pour cet usage. D'autant que l'amélioration du support de l'UEFI dans les offres de machines virtuelles permet un tel changement.

Les partitions chiffrées avec LUKS auront la taille du secteur défini automatiquement, suivant le matériel sous-jacent pour améliorer les performances. Jusqu'ici, l'installateur Anaconda fixait la taille à 512 octets par secteur, peu importe la réalité du matériel utilisé. Cela devrait être de 4096 octets par secteur dans la majorité des cas. Sur un SSD connecté par NVMe, le gain estimé est d'environ 2-3% de performances.

Internationalisation

IBus est proposé à la version 1.5.25. La version proposée apporte l'usage d'un seul script transfiletriggerin pour générer le fichier de cache des méthodes d'entrées plutôt que l'ancienne méthode qui reposait sur plusieurs scripts posttrans plus difficiles à maintenir. Derrière le capot ce script est appelé par la commande ibus write-cache qui va écrire les fichiers de cache dans le dossier /usr/share/ibus/component.

La composition des caractères suit maintenant la méthode implémentée dans GTK+4, si vous souhaitez saisir par exemple le caractère à, il faut saisir avec la touche de composition le caractère <nowiki>`</nowiki> puis la touche a. Mais avant, si le caractère ne supportait pas cet accent, par exemple la lettre x, rien n'était affiché car c'est invalide. Maintenant cela va afficher <nowiki>`</nowiki>x séparément. Cela simplifie notamment la saisie de <nowiki>```</nowiki> très utilisé avec le langage markdown. L'intégration avec GTK+4 est de manière générale améliorée.

Le raccourci clavier pour accéder aux émojis passent de Ctrl+Shift+e à Ctrl+, par défaut.

La méthode d'entrée par défaut pour les langues indo-aryennes passe de Inscript vers Enhanced Inscript keymaps. L'objectif est d'utiliser le dernier standard indien sur le sujet avant son inclusion progressive dans GNOME en amont.

GNOME-Multitache.png, oct. 2021

Administration système

L'image de base de Fedora ne fournit plus les paquets sssd-client et util-linux pour réduire la taille des conteneurs avec Fedora. On gagne ainsi 13 Mio sur les 122 Mio de l'image minimale soit un gain d'environ 10%.

En lien avec ce changement, le cache de SSSD pour les utilisateurs locaux peut être activé ou désactivé à chaud, et il n'est plus lancé par défaut dorénavant. Cela permet d'avoir un système pleinement fonctionnel même quand il est manquant, et de limiter son impact sur le système quand on n'en a pas besoin.

L'installateur Anaconda prend en charge des fichiers de profil et non plus des fichiers de configuration de produits pour être plus générique.

En fait dans le dossier /etc/anaconda/profile.d, il y a plusieurs fichiers pour configurer l'installation. Par exemple le fichier de configuration fedora-workstation.conf défini que l'environnement par défaut c'est Workstation (qui de fait est GNOME), il spécifie un fichier CSS pour l'habillage d'Anaconda, puis il dit aussi d'ignorer la configuration de l'utilisateur et du réseau car cela est géré au niveau de GNOME. Si on regarde du côté du serveur on a le fichier fedora-server.conf qui définie que le partitionnement par défaut doit utiliser LVM avec un système de fichier xfs d'au moins 2 Gio pour la racine.

C'est en somme la logique qui permet avec un seul logiciel de gérer des configurations différentes sans trop de maintenance. Seulement le choix de ces fichiers se basaient sur les éléments suivants dans l'ordre :

  • Les paramètres du noyau inst.product et inst.variant ;
  • Les variables Product et Variant dans le fichier .buildstamp ;
  • Ou la variable NAME du fichier /etc/os-release.

Seulement cela était fragile car reliés aux noms officiels de Fedora Linux et de ses variants. Le nom du système a changé (lire plus bas), cela imposait des astuces pour gérer le cas des images boot.iso ou Live en créant notamment des faux produits.

Pour simplifier cela la conception repose sur des identifiants uniques à la place. L'option du noyau devient alors inst.profile et les variables ID et VARIANT_ID pour le fichier os-release.

L'image Fedora Cloud utilise le système de fichiers btrfs par défaut. Cela rejoint Fedora Workstation qui s'en sert depuis la version 33. Ainsi cette image peut tirer parti des avantages de btrfs comme la compression transparente, l'intégration des cgroups, les clichés système, le redimensionnement ou la gestion automatique des sous-volumes.

Les mots de passe des utilisateurs dans /etc/shadow sont hashés par yescrypt par défaut. Cela suit les distributions ALT Linux, Debian testing, et Kali Linux 2021.1+ qui ont déjà fait ce choix. Les avantages de yescrypt par rapport à sha256crypt et sha512crypt utilisés jusqu'ici sont :

  • Il peut avoir plus de 90 bits d'entropie pour le sel, à savoir au delà des 120 bits recommandée par la NIST ;
  • Il est plus difficile de faire un déni de service au niveau du CPU en lui soumettant des mots de passe longs ;
  • C'est plus difficile de deviner la longueur du mot de passe en fonction du temps de traitement ;
  • Il utilise une fonction de dérivation de clé.

La mise à jour d'un paquet ayant un service systemd au niveau utilisateur mènera à son relancement à la fin de la mise à jour. Auparavant cela n'était fait que pour systemd en tant que PID 1 au niveau système. Ces services sont identifiables avec le nom user@<uid>.service qui répondent aux commandes systemd --user. Cela est particulièrement utile pour pouvoir relancer le service de pipewire pour la gestion du son.

Le gestionnaire de virtualisation libvirt a un démon par module dorénavant pour plus de souplesse et de fiabilité. Le service libvirtd.service est supprimé en faveur de virtqemud.service, virtxend.service, virtlxcd.service, virtinterfaced.socket, virtnetworkd.socket, virtnodedevd.socket, virtnwfilterd.socket, virtproxyd.socket, virtsecretd.socket et virtstoraged.socket.

GNOME-Energie.png, oct. 2021

Ainsi seuls les services nécessaires sont lancés ce qui peut réduire significativement le temps de chargement de libvirt. Et en cas de problème dans un service, les autres peuvent potentiellement tourner sans problèmes ce qui n'était pas le cas avant, une erreur était fatale à l'ensemble. SELinux pourra aussi à terme en tirer profit pour avoir une politique plus fine, la politique actuelle étant assez large car devant autoriser quasiment tout à libvirt qui en avait besoin.

La bibliothèque Cyrus SASL passe de Berkeley DB à GDBM pour la gestion des bases de données. Les paquets concernés auront leurs bases de données automatiquement converties via la commande :

cyrusbdb2current <sasldb path> <new_path>

Cela est dû entre autres à la licence de libdb qui est devenue plus restrictive.

Mise à jour du pare-feu dynamique firewalld à la version 1.1.0. Cette version s'autorise un toilettage bienvenu en réduisant ses dépendances, en supprimant le support de tftp-client et de Python 2 alors que iptables et l'interface Direct sont dépréciés. Les règles NAT sont déplacées dans la famille inet ce qui réduit la taille des règles pour les utilisateurs d'ipset, qui étaient jusqu'ici dupliquées entre IPv4 et IPv6. La cible défaut est proche de la cible rejet pour améliorer la cohérence dans leur comportement. Le premier n'autorise en plus que les paquets ICMP. Deux zones de même niveau de confiance peuvent également s'échanger des paquets ce qui est le comportement attendu avec les autres pare-feu ayant le concept de zones.

Suppression du paquet authselect-compat, de fait l'outil authconfig disparaît au profit de authselect qui est mis par défaut depuis Fedora 28.

Le paquet libusb est renommé libusb-compat-0.1 et libusbx en libusb1. Ce nommage est plus conforme avec la nomenclature du projet officiel.

Mise à jour de RPM à la version 4.17. Les erreurs à l'installation sont mieux gérées. Les macros sont améliorées et peuvent se complexifier en tirant profit d'une meilleure intégration du langage Lua. Les bibliothèques n'ont plus besoin de la permission exécutable pour la génération des dépendances ce qui améliore la qualité des paquets.

Développement

La collection d'outils binutils passe à la version 2.37. Il prend en charge notamment plus d'instructions des architectures x86_64 et AArch64. L'éditeur de liens et l'assembleur bénéficient de plus d'options.

La bibliothèque C Glibc 2.34 est proposée. Les bibliothèques libpthread, libdl, libutil et libanl sont inclus dans la libc, rendant inutile l'ajout de ces bibliothèques lors de l'édition des liens. Des bibliothèques statiques vides sont fournies pour garantir la compatibilité avec l'existant. Sinon beaucoup de nettoyage et de changements mineurs, comme le support des dernières fonctions du noyau Linux.

La suite LLVM passe la 13e version. Les paquets llvm12 et clang12 sont fournis pour garantir la compatibilité. Cette version apporte un nouveau frontend pour le langage Fortran : Flang. Ajout de la prise en charge de quelques instructions Armv9-A : Realm Management Extension (RME) et Scalable Matrix Extension (SME). Clang gère mieux OpenCL et utilise par défaut sa version 1.2. Et d'autres changements divers dans le formateur de code de Clang et son analyseur statique.

La bibliothèque généraliste de C++, Boost, appuie sur le champignon jusqu'à la version 1.76. Comme souvent, beaucoup d'améliorations diverses dans l'ensemble des modules. De manière plus notable, le module Boost.Math abandonne la prise en charge de C03, tandis que Boost.Multiprecision exige du code compilé en C1 ou supérieur. Le module Boost.DLL renomme boost::dll::import en boost::dll::import_symbol pour éviter une collision de nommage avec la nouvelle norme C++20.

Node.js 16 est proposé par défaut. Les versions 14 et 12 restent disponibles dans les modules facultatifs. Le moteur JavaScript passe ainsi à la version 9.4 qui améliore les performances et fournit les dernières fonctionnalités de JavaScript. De même que l'utilitaire npm évolue avec la version 8.0.0. Le support expérimental des Web Streams API est introduit.

Le langage Python 3.10 est déployé pendant que Python 3.5 est entièrement retiré. Les nouveaux mots clés match / case sont introduits pour le filtrage par motif, fonctionnalité qu'on retrouve dans de nombreux langages modernes ou fonctionnels. Les messages d'erreurs sont aussi plus clairs avec des suggestions de correction.

Le célèbre générateur de documentation en Python, Sphinx, veille sur la 4e version. Il passe notamment à la version 3 de MathJax pour les formules mathématiques. Il prend en charge docutils-0.17 pour le rendu.

Le langage Perl perle vers la version 5.34. La syntaxe expérimentale pour les exceptions try/catch est ajoutée. Il est possible d'utiliser une autre syntaxe pour les nombres en octal avec 0o123_456. Enfin il est possible d'ajouter librement des espaces au sein d'accolades comme \x{ FFFC }. Une fuite mémoire importante dans le module des expressions régulières a été colmatée.

Le langage de programmation fonctionnelle et concurrente Erlang 24 est disponible. Parmi les nouveautés il y a un nouveau compilateur JIT BeamAsm remplaçant le compilateur haute performance HiPE. Le module graphique wx a été entièrement réécrit basé sur la version 3 de la bibliothèque wxWidgets qui fourni aussi wxWebView.

Son voisin Haskell bénéficie du compilateur GHC 8.10 et de sa distribution Stackage version 18. Il embarque un backend LLVM 9 pour la compilation. Il propose aussi un ramasse miette avec une faible latence. Une amélioration des performances est noté pour le filtrage par motif. Le langage bénéficie de quelques extensions.

Le langage PHP 8.0 fait son apparition. Tout d'abord il introduit deux compilateurs JIT pour être évalués, offrant des performances similaires à la voie classique pour les grosses applications type Wordpress. Il apporte la possibilité de nommer les arguments lors de l'appel à une fonction pour améliorer la souplesse et la lisibilité. Comme Python il ajoute le mot clé match pour faire du filtrage par motif. Le Nullsafe est introduit pour éviter lors d'une chaine d'appels de devoir vérifier si chaque élément est non null, si un des éléments est null, l'évaluation de la chaine s'arrête automatiquement ce qui améliore la fiabilité et la lisibilité. Enfin la comparaison entre un nombre et une chaine de caractère est plus logique et le comportement plus cohérent.

L'environnement de compilation de binaires Windows, MinGW, est proposé à la version 9.0.0. Son apport principal est la modernisation de la chaine de compilation GNU avec GCC 11 notamment.

La bibliothèque graphique SDL 2.0 fournira la gestion de la compatibilité avec la version 1.2, plutôt que l'installation de cette ancienne version. Cela signifie que le paquet sdl12-compat est supprimé tout en permettant d'exécuter des jeux n'ayant pas migrés. Ce changement apporte de nombreux avantages comme la prise en charge correcte de Wayland pour l'affichage, de Pipewire pour l'audio et des manettes. De plus, SDL 2.0 étant maintenu contrairement à cette vieille version, les correctifs futurs pourront bénéficier à ces applications aussi.

Le paquet libmemcached utilise le code de libmemcached-awesome au lieu du projet d'origine, qui n'est plus maintenu depuis 7 ans. Le tout reste compatible au niveau API et ABI.

Debuginfod est utilisé par défaut pour obtenir les codes source et autres données de débogage en cas de nécessité, plutôt que de recourir à l'installation des paquets de débogage correspondant. Grâce à ce protocole, en cas de besoin, il téléchargera les ressources nécessaires depuis les serveurs de Fedora dédiés ce qui est plus simple pour l'utilisateur, léger car tout le contenu du paquet n'est pas téléchargé et évite de polluer la base de données RPM avec des paquets qui ne serviront que temporairement.

Actuellement les fichiers ne sont conservés qu'une semaine en cache sur le disque dans le répertoire $HOME/.cache, mais cela est configurable ou peut être nettoyé à la main. Un minimum d'info est envoyé par HTTPS vers les serveurs de Fedora, pour essayer de conserver la confidentialité des utilisateurs : adresse IP, hash du contenu demandé, le nom du fichier source demandé, un User-Agent contenant l'architecture de la machine et la version de Fedora employée.

GNOME-Menu_energie.png, oct. 2021

Projet Fedora

Le fichier /etc/os-release renvoie le nom du système comme Fedora Linux et non Fedora. Cela met en avant la distinction entre le projet Fedora, son écosystème et Copr par rapport au système lui même, qui s'appelle Fedora Linux maintenant. Les produits spécifiques gardent quant à eux la dénomination usuelle, par exemple Fedora Workstation n'est pas renommée car il n'y a pas de confusion possible.

Chez les plus anciens cela évoque la fusion des dépôts Core et Extras ayant mené au renommage de Fedora Core en Fedora pour la magnifique version 7, sortie en 2007, il y a 14 ans déjà.

La politique de choix du compilateur pour générer un paquet évolue pour laisser plus de latitude à l'empaqueteur. GCC ou Clang/LLVM peuvent être choisis par l'empaqueteur même si GCC est pleinement supporté ou non par le logiciel en question. Avant seulement GCC devait être utilisé, sauf si le projet ne gérait officiellement que Clang. Cette souplesse pour l'empaqueteur doit permettre de limiter la perte de temps en compilant le projet avec un compilateur qu'il maitrise mal, ou moins bien testé par le logiciel à compiler. Cette décision ne concerne pas le débogueur, ni l'éditeur de lien ou autres outils intervenant dans la chaine de compilation.

La politique pour les paquets de Python a été mise à jour pour favoriser le travail commun avec Python et les autres distributions. L'idée est que le nom employé par le répertoire d'installation du paquet corresponde au nom utilisé par la PyPI pour ce même projet, au lieu d'utiliser le nom du paquet RPM qui ne correspond pas toujours. Cela permet de mieux faire le lien entre les deux mondes et d'éviter les conflits avec des projets Python installés autrement que par RPM.

Par ailleurs, moins de paquets Python vont dépendre de python3-setuptools. En effet cet outil est de moins en moins utilisé par l'écosystème Python pour concevoir des paquets, au profit de poetry ou flit ce qui rendait cette dépendance systématique lourde et inutile.

Un nouveau paquet glibc-gconv-extra est ajouté pour prendre en charge les formats d'encodage en dehors de UTF-*, unicode, ISO-8859-1, ISO8859-15, CP1252 et ANSI_X3.110 pour gagner 8 Mio sur une image minimale. En effet seuls ces formats sont proposés par défaut avec Glibc. Cela permet aussi de plus facilement retirer des modules pour des encodages peu utilisés, et donc peu testés avec potentiellement des bogues et des failles associées. Seule l'image de compilation du projet Fedora ne l'installe pas par défaut pour l'instant.

Les paquets seront compilés sans -ffat-lto-objects par défaut, les paquets qui en ont besoin devront l'ajouter eux même. Avec cette option, les fichiers objets étaient compilés et optimisés avec un langage intermédiaire LTO et étaient compilés normalement en même temps. Cela permettait d'utiliser les objets optimisés par LTO ou non selon les besoins. Supprimer par défaut cette option permet de supprimer l'étape de la compilation normale, seuls les objets optimisés avec LTO sont générés et exploités. Du coup on gagne du temps de compilation pour le paquet et on réduit la charge sur les serveurs de compilation.

Import de la macro OpenSUSE pour définir la mémoire minimale nécessaire par constructeur du paquet durant le parallélisme :

%limit_build -m 8192

pour éviter que les gros projets comme ceph, chromium oumcrouter échouent par manque de mémoire disponible. Chromium peut par exemple en réclamer plus de 8 Gio en cas de compilation parallèle sur 4 cœurs à lui tout seul. Ces projets devaient jouer sur la variable _smp_build_ncpus pour réduire le nombre de CPUs disponibles pour limiter le pic de consommation mémoire, ce qui n'est pas très fiable d'une part, et d'autre part chaque mainteneur réinventait la roue sur le sujet ce qui dégradait les performances de compilation en dehors de ces pics mémoire importants.

Lors de la construction d'un paquet RPM, le chemin RPATH sera vérifié et pourra faire échouer la génération du paquet s'il ne respecte pas les consignes du projet Fedora. Certains logiciels utilisent cette variable pour outrepasser l'éditeur de lien dynamique qui cherche les bibliothèques nécessaires à l'exécution du logiciel dans le système. Si cela peut être utile pour pointer vers des répertoires privées et de fait non standard, si cela est mal fait cela peut rendre la variable LD_LIBRARY_PATH inopérante pour l'utilisateur ou de présenter un risque de sécurité car le chemin pointé n'est pas géré par le système avec potentiellement un accès large en écriture.

N'est plus accepté :

  • Un RPATH pointant vers /usr/lib ou /usr/lib64 qui sont standards et donc redondants ;
  • Les chemins invalides ;
  • Les chemins relatifs pour des raisons de sécurité ;
  • Un chemin vide ;
  • Tout chemin contenant .. .

Les champs Release et changelog d'un paquet RPM peuvent être autogénérés par rpmautospec. Ces macros se basent sur les informations fournies par git pour définir la version et les changements opérés depuis la dernière fois, ce qui peut permettre de gagner du temps pour l'empaquetage des paquets en réduisant l'intervention manuelle.

La communauté francophone

L'association

Logo.png, oct. 2017

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

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.

L'équipe se réunit tous les lundis soir après 21h (heure de Paris) sur IRC (canal #fedora-doc-fr sur Libera) pour faire progresser la documentation par un travail collaboratif. Le reste de la semaine cela 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 35 ?

Mediawriter.png, oct. 2018

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

Sortie de Fedora Linux 35 Beta

Charles-Antoine Couret

En ce mardi 28 septembre, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 35.

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

La version finale est pour le moment fixée pour le 19 ou 26 octobre.

Expérience utilisateur

  • Passage à GNOME 41 ;
  • En lien avec la nouvelle fonctionnalité de GNOME concernant l'énergie, Fedora installe par défaut le paquet power-profiles-daemon pour contrôler via DBus la politique énergétique du système entre performance, équilibré ou économie d'énergie ;
  • GNOME Logiciels et GNOME Initial Setup proposent une option à l'utilisateur pour activer des dépôts tiers ;
  • Ajout d'un dépôt tiers nommé fedora-flathub-filter qui expose des applications Flatpaks provenant de Flathub sélectionnées par Fedora. L'installation usuelle de Flathub reste nécessaire pour accéder à l'ensemble de ses applications ;
  • WirePlumber va gérer les sessions Pipewire pour l'audio dorénavant plutôt que ce que Pipewire utilise en interne ;
  • Le système Fedora Kinoite devient une variante officielle. C'est l'équivalent de Fedora Silverblue avec KDE Plasma comme environnement graphique par défaut.

Gestion du matériel

  • L'image Fedora Cloud prend en charge le mode hybride BIOS et UEFI pour le démarrage de la machine ;
  • Les partitions chiffrées avec LUKS auront la taille du secteur défini automatiquement, suivant le matériel sous-jacent pour améliorer les performances. Jusqu'ici la taille était fixe à 512 octets par secteur, cela devrait être de 4096 octets par secteur dans la majorité des cas.

Internationalisation

  • IBus est proposé à la version 1.5.25 ;
  • La méthode d'entrée par défaut pour les langues indo-aryennes passe de Inscript vers Enhanced Inscript keymaps.

Administration système

  • L'image de base de Fedora ne fournit plus les paquets sssd-client et util-linux pour réduire la taille des conteneurs avec Fedora ;
  • L'installateur Anaconda prend en charge des fichiers de profil et non plus des fichiers de configuration de produits pour être plus générique.
  • systemd-resolved prend en charge DNS over TLS (DoT) si le serveur DNS configuré par l'utilisateur supporte cette fonctionnalité. Cela ajoute une couche cryptographique aux requêtes DNS ;
  • L'image Fedora Cloud utilise le système de fichiers btrfs par défaut ;
  • Les mots de passe des utilisateurs dans /etc/shadow sont hashés par yescrypt par défaut ;
  • La mise à jour d'un paquet ayant un service systemd au niveau utilisateur mènera à son relancement à la fin de la mise à jour. Auparavant cela n'était fait que pour systemd en tant que PID 1 au niveau système ;
  • Le gestionnaire de virtualisation libvirt a un démon par module dorénavant pour plus de souplesse et de fiabilité. Le service libvirtd.service est supprimé en faveur de virtqemud.service, virtxend.service, virtlxcd.service, virtinterfaced.socket, virtnetworkd.socket, virtnodedevd.socket, virtnwfilterd.socket, virtproxyd.socket, virtsecretd.socket et virtstoraged.socket ;
  • La bibliothèque Cyrus SASL passe de Berkeley DB à GDBM pour la gestion des bases de données. Les paquets concernés auront leurs bases de données automatiquement convertis via la commande :
cyrusbdb2current <sasldb path> <new_path>
  • Le cache de SSSD pour les utilisateurs locaux peut être activé ou désactivé à chaud, et il n'est plus lancé par défaut dorénavant.
  • Mise à jour du parefeu dynamique firewalld à la version 1.1.0 ;
  • Suppression du paquet authselect-compat, de fait l'outil authconfig disparaît au profit de authselect qui est mis par défaut depuis Fedora 28 ;
  • Le paquet libusb est renommé libusb-compat-0.1 et libusbx vers libusb1 ;
  • Mise à jour de RPM à la version 4.17.

Développement

  • La collection d'outils binutils passe à la version 2.37 ;
  • La chaine de compilation GNU est mise à jour avec GCC 11, Glibc 2.34 et GDB 10.2 ;
  • De même pour la suite LLVM pour leur 13e version ;
  • La bibliothèque généraliste de C++, Boost, appuie sur le champignon jusqu'à la version 1.76 ;
  • Node.js 16 est proposé par défaut. Les versions 14 et 12 restent disponibles dans les modules facultatives ;
  • Le langage Python 3.10 est déployé pendant que Python 3.5 est entièrement retiré ;
  • Le célèbre générateur de documentation en Python, Sphinx, veille sur la 4e version ;
  • Le langage Perl perle vers la version 5.34 ;
  • Le langage de programmation fonctionnelle et concurrente Erlang 24 est disponible ;
  • Son voisin Haskell bénéficie du compilateur GHC 8.10 et de sa distribution Stackage version 18 ;
  • Le langage PHP 8.0 fait son apparition ;
  • L'environnement de compilation de binaires Windows, MinGW, est mis à jour ;
  • La bibliothèque graphique SDL 2.0 fournira la gestion de la compatibilité avec la version 1.2, plutôt que l'installation de cette ancienne version ;
  • Le paquet libmemcached utilise le code de libmemcached-awesome au lieu du projet d'origine, qui n'est plus maintenu depuis 7 ans. Le tout reste compatible au niveau API et ABI ;
  • Debuginfod est utilisé par défaut pour obtenir les codes source et autres données de débogage en cas de nécessité, plutôt que de recourir à l'installation des paquets de débogage correspondant.

Projet Fedora

  • Le fichier /etc/os-release renvoie le nom du système comme Fedora Linux et non Fedora. Cela met en avant la distinction entre le projet Fedora et le système lui même, qui s'appelle Fedora Linux maintenant ;
  • La politique de choix du compilateur pour générer un paquet évolue pour laisser plus de latitude à l'empaqueteur. GCC ou Clang/LLVM peuvent être choisis par l'empaqueteur même si GCC est pleinement supporté ou non par le projet en question. Avant seulement GCC devait être utilisé, sauf si le projet ne gérait officiellement que Clang ;
  • La politique pour les paquets de Python a été mise à jour pour favoriser le travail commun avec Python et les autres distributions ;
  • Par ailleurs, moins de paquets Python vont dépendre de python3-setuptools ;
  • Un nouveau paquet glibc-gconv-extra est ajouté pour prendre en charge les formats d'encodage en dehors de UTF-*, unicode, ISO-8859-1, ISO8859-15, CP1252 et ANSI_X3.110 pour gagner 8 Mio sur une image minimale, seuls ces formats sont proposés par défaut avec Glibc ;
  • Les paquets seront compilés sans -ffat-lto-objects par défaut, les paquets qui en ont besoin devront l'ajouter eux même ;
  • Import de la macro OpenSUSE pour définir la mémoire minimale nécessaire par constructeur du paquet durant le parallélisme :
%limit_build -m 8192

Pour éviter que les gros projets comme chromium échouent par manque de mémoire.

  • Lors de la construction d'un paquet RPM, le chemin RPATH sera vérifié et pourra faire échouer la génération du paquet s'il ne respecte pas les consignes du projet Fedora ;
  • Les champs Release et changelog d'un paquet RPM peuvent être autogénérés par rpmautospec.

Tester

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

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

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

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

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

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

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

Bons tests à tous !

[F35] Participez à la semaine de tests chargée : noyau 5.14, GNOME 41, Audio et internationalisation

Charles-Antoine Couret

Aujourd'hui, cette semaine de début septembre, est une semaine dédiée à plusieurs tests : noyau 5.14, GNOME 41, Audio et internationalisation En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

Nous sommes proches de la diffusion de Fedora 35 édition Beta. De nombreuses nouveautés sont bien avancées dans leur développement et doivent être fiabilisés avant la version finale qui sortira fin octobre.

Les tests pour le noyau sont :

Pour GNOME 41 ils consistent en :

  • La détection de la mise à niveau de Fedora par GNOME Logiciels ;
  • Le verrouillage et déverrouillage d'écran ;
  • Le bon fonctionnement du navigateur Web, de Cartes, de Musique, de Disques et du Terminal ;
  • La connexion / déconnexion et changement d'utilisateurs ;
  • Le fonctionnement du son, notamment détection de la connexion ou déconnexion d'écouteurs ou casques audios ;
  • Le fonctionnement global du bureau : les activités, les paramètres, les extensions.
  • Possibilité de lancer les applications graphiques depuis le menu.

Pour l'audio, cela vérifie :

  • Vérifier que pipewire est bien utilisé par défaut ;
  • Le fonctionnement des applications avec de l'audio, avec ALSA ou Jack comme backend ;
  • La configuration du son dans le centre de contrôle de GNOME et de pavucontrol ;
  • La gestion des périphériques audio dont par Bluetooth.

Enfin pour linternationalisation c'est :

  • Le bon fonctionnement d'ibus pour la gestion des entrées claviers ;
  • La personnalisation des polices de caractères ;
  • L'installation automatique des paquets de langues des logiciels installés suivant la langue du système ;
  • La traduction fonctionnelle par défaut des applications ;
  • Les nouvelles dépendances des paquets de langue pour installer les polices et les entrées de saisie nécessaires.

Comment y participer ?

Le calendrier pour cette semaine est comme suit :

Visitez ces pages le jour J, suivez les instructions et communiquez vos résultats dessus.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Libera.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une semaine est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Résultats des élections de Fedora 06/21

Charles-Antoine Couret

Le scrutin est comme toujours un vote par valeurs. Nous pouvons attribuer à chaque candidat un certain nombre de points, dont la valeur maximale est celui du nombre de candidat, et le minimum 0. Cela permet de montrer l'approbation à un candidat et la désapprobation d'un autre sans ambiguïté. Rien n'empêchant de voter pour deux candidats avec la même valeur.

Les résultats pour le Conseil sont (seul le premier est élu) :

  # votes |  noms
  - --------+----------------------
 496    Aleksandra Fedorova
  - --------+----------------------
 333    Eduard Lucena
 234    Damian Tometzki

À titre indicatif le score maximal possible était de 226 * 3 votes soit 678 votes.

Les résultats pour le FESCo sont (seuls les quatre premiers sont élus) :

  # votes |  noms
- --------+----------------------
 1156   Neal Gompa
 931    Stephen Gallagher
 804    Dan Čermák
 771    Mohan Boddu
- --------+----------------------
 716    František Zatloukal
 602    Robbie Harwood
 564    Frank Ch. Eigler

À titre indicatif le score maximal possible était de 241 * 7 soit 1687.

Les résultats pour le Mindshare sont donc (seul le premier est élu):

     # votes |  noms
     - --------+----------------------
     168        Onuralp Sezer
     - --------+----------------------

Oui il n'y avait qu'un seul candidat. À titre indicatif le score maximal possible était de 190 * 1 soit 190.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin avec un réel enjeu était proche aux alentours de 250-190 votants ce qui est un peu en deçà de l'édition précédente. Les scores sont aussi plutôt éparpillés.

Bravo aux participants et aux élus et le meilleur pour le projet Fedora.

AMC version 1.4.0 Fedora 34

Patrice Kadionik

Les RPM d'AMC (Auto Multiple Choice) version 1.4.0 pour Fedora 34 sont disponibles dans le dépôt eddy33.


Installation :

$ sudo dnf install perl-Gtk3 perl-Clone
$ sudo dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/eddy33-release-34.rpm
$ sudo dnf install auto-multiple-choice
++

Fin de maintenance de Fedora 32

Charles-Antoine Couret

C'est en ce mardi 25 mai 2021 que Fedora 32 que la maintenance de Fedora 32 prend fin.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 34, la version n-2 (donc Fedora 32) n'est plus maintenue.

Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 32 et antérieurs d'effectuer la mise à niveau vers Fedora 34 ou 33.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 33 ou 34. N'hésitez pas à lancer la mise à niveau par ce biais.

Revue de presse de Fedora 34

Charles-Antoine Couret

Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora 34 !

Bien entendu je passe sous silence mon blog et le forum de fedora-fr. Je prends le parti pris de parfois pointer les annonces de la Bêta quand elles sont plus complètes pour décrire les nouveautés que pour la version finale. C'est notamment le cas de NextINpact qui évidemment ont toujours un petit mot que la version sort en version finale. ;-)" class="smiley

Sites web d'actualité

Soit 5 sites sur les 25 contactés.

Blogs, sites persos ou sites non contactés

Soit 4 sites.

Bilan

Le nombre de sites parlant de Fedora 34 est stable.

La semaine de sa sortie, nous avons eu globalement une augmentation de visites par rapport à la semaine d'avant de cet ordre là :

  • Forums : hausse de 14,8% (environ 800 visites en plus)
  • Documentation : hausse d'environ 4,7% (soit environ 250 visites en plus)
  • Le site Fedora-fr : hausse de 23,8% (soit 130 visites en plus)
  • Borsalinux-fr : hausse de 227% (soit 41 visites en plus)

Si vous avez connaissance d'un autre lien, n'hésitez pas à partager ! Rendez-vous pour Fedora 35.

Rétrospective de l'adoption du nouveau logo de Fedora

Charles-Antoine Couret

Léquipe design de Fedora a travaillé depuis fin 2018 sur un changement du logo de Fedora. Léquipe a proposé deux possibilités et obtenu des retours constructifs, permettant d'aboutir au résultat final.

Si vous lisez langlais ou si vous souhaitez voir lensemble des tests intermédiaires, je vous conseille de lire cet excellent article qui présente le sujet. Ce qui suit en résume lessentiel.

fedora_logo.svg, avr. 2021

Historique

Il y a déjà eu deux versions du logo de Fedora, comme vous pouvez le voir ci‐dessous. Ce nest donc pas un changement inédit même si le précédent date un peu, à savoir vers lannée 2005.

Premier logo : Fedora_Core.png, janv. 2019

Second et actuel logo : fedora-2005.png, janv. 2019

Pourquoi ce changement ?

Logo complexe à travailler

Tout dabord il y a un problème dans le rendu. Le logo actuel contient plusieurs couleurs, ce qui complexifie la réalisation de produits dérivés ou les rend plus chers suivant le prestataire. Cest un élément important pour la réalisation de la communication autour du projet.

Fedora-décomposition.png, janv. 2019

Ensuite, cela rend le logo plus difficilement visible en cas de fond foncé, en particulier avec un fond bleu. Cela est particulièrement le cas pour la réalisation de fonds décran ou de pochettes CD. Pour les pochettes CD, il nétait pas rare que léquipe graphique ruse un peu en utilisant un dégradé de bleu et en positionnant le logo de Fedora sur la partie claire. Mais pour le rendu dun site Web, il est plus délicat de sassurer de la position du logo par rapport à la clarté du bleu du fond de page, suivant la taille de lécran du visiteur.

Jacquette-F12.png, janv. 2019

De par la composition du logo — un texte plus la bulle avec le fameux F —, il est difficile de centrer les éléments et de calculer les espaces entre les éléments, que ce soit pour un centrage vertical ou horizontal.

Enfin, la police choisie à lépoque souffre dun défaut. Le a final ressemble trop à un o, ce qui gêne, bien entendu, la communication.

Confusion possible

La bulle de Fedora avec son F ressemble trop au logo de Facebook. Si cela peut prêter à sourire, les logos étant quand même différents, il est en effet courant (pour lavoir vécu comme dautres ambassadeurs) que les personnes qui ne sont pas du milieu confondent les deux. Et, en effet, cest une remarque apparemment récurrente depuis 2009-2010, quand le réseau social a commencé à se répandre.

Question de cohérence, pour la liberté !

Fedora se veut être une distribution libre. Cest un élément important du projet. Mais jusquici la police choisie pour former le texte du logo nétait pas libre. Cest en effet la version 2005 de Bryant. À lépoque, cétait justifié car il y avait assez peu de polices libres de qualité, mais depuis les temps ont changé. Red Hat, Google, dautres entreprises et des amateurs ont travaillé sur la question, le choix aujourdhui est bien plus large. Pour respecter les principes du projet, abandonner une police propriétaire semble évident.

Cheminement

Le travail a été amorcé suite à une discussion au sein du Conseil en octobre 2018. Qui a mené à louverture dun ticket auprès de léquipe design. Il y a eu pas mal dessais et de réflexion en jouant sur le logo. Jouer sur le F, le symbole infini, sur la perspective ou encore en modifiant la bulle.

Ce nest pas une décision qui a été prise à la légère, changer un logo a un gros impact. Il faudra en effet changer toutes les références de ce logo au fur et à mesure. Sur le site du projet ainsi que sur les sites non officiels, mais liés à Fedora comme fedora-fr.org.

Mais à cause de linertie du logo actuel, adopter le prochain prendra du temps. Que ce soit dans les sites dactus, dans les produits dérivés employés et distribués, sur les différents sites où Fedora est mentionnée comme Wikipédia, etc.

C'est pourquoi le processus a pris du temps. Début janvier 2019 seulement l'équipe graphique a proposé à la communauté deux propositions, visibles plus bas, afin de collecter des retours pour améliorer le rendu et choisir l'un des deux.

Et finalement fin mars 2019, le Conseil de Fedora a rendu son verdict final, ce qui a autorisé d'entamer les procédures pour son adoption, comme vérifier auprès des avocats de Red Hat si ce logo ne pose pas de problèmes ou débuter la campagne de promotion pour son adoption définitive.

Résultat

Les deux illustrations sont les premières propositions qui montrent les différentes déclinaisons du logo et donnent un exemple dusage. La police retenue est Confortaa de Johan Aakerlund. Elle a été légèrement modifiée pour loccasion.

Voici la première proposition : Proposition1.png, janv. 2019

Et la deuxième : Proposition2.png, janv. 2019

La version définitive choisie s'est basée sur la première proposition car elle plus proche du logo actuel. Elle a été retravaillée à partir des différents avis, ce peaufinage est expliqué sur le blog de Máirín Duffy. Et voici le rendu final :

Nouveau_logo_final_de_Fedora.png, avr. 2021

Fedora 34 sort orné d'un nouveau logo

Charles-Antoine Couret

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

Fedora 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 peut se voir comme une sorte de vitrine technologique pour le monde du logiciel libre, cest 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 dun certain nombre de logiciels libres contenus dans la distribution, dont le noyau Linux, GNOME, NetworkManager, PackageKit, PulseAudio, Wayland, systemd, la célèbre suite de compilateurs GCC, etc. Cliquez ici pour voir lensemble des contributions de Red Hat.

Cela a été aussi abordé dans une série d'articles ici, et par ici encore.

GNOME-Bureau.png, avr. 2021

Notons que cette nouvelle version de Fedora introduit la nouvelle version de son logo, dont l'historique et les détails sont fournis dans un autre article.

fedora_logo.svg, avr. 2021

Expérience utilisateur

Passage à GNOME 40. Derrière ce changement de numérotation, abandonnant le format 3.x se cachent plusieurs changements d'envergure.

Si l'interface du bureau semble inchangée en prime abord, les bureaux virtuels sont organisés de manière horizontale et non plus verticale. Cela correspond mieux à l'organisation de ces espaces de travail dans les autres systèmes ou même chez GNOME 2 en son temps. La nouvelle ergonomie est mieux adaptée en cas d'usage multi écran, les écrans étant souvent placés les uns à côté des autres.

Le dock applicatif est aussi situé en bas et dispose d'une séparation entre les applications épinglées de celles en cours d'exécution seulement.

Le navigateur Web a de nouveaux onglets, qui peuvent maintenant défiler et avec un style plus cohérent avec le reste des applications GNOME. Il peut afficher aussi les suggestions de recherches de Google, en option.

Le navigateur de Fichiers bénéficie d'une meilleure estimation du temps restant pour les opérations comme les copies ou les suppressions. Il prend en charge la saisie d'un mot de passe pour extraire une archive. L'interface des préférences des applications a été remaniée.

Le centre de contrôle a déplacé les paramètres concernant la disposition clavier de Pays et langues vers Clavier pour des raisons ergonomiques. Si votre constructeur l'a renseigné dans l'UEFI, le nom du modèle de votre machine apparaît dans À propos.

L'application Cartes peut afficher des infobulles concernant des lieux en se basant sur le contenu de Wikipédia, et il peut afficher le nom local du lieu également.

L'application Météo a été graphiquement rafraîchie, avec possibilité de voir le détail sur 48h ou le global sur dix jours. Graphiquement aussi beaucoup d'icônes des applications GNOME ont été redessinées ou des parties de l'interface modernisées comme dans Fichiers, Web, Disques, Polices, Agenda, Photos et Moniteur système.

L'environnement de bureau Xfce fait tourner la roue vers sa version 4.16. Cette version majeure débute par d'importants changements graphiques. La palette de couleurs et les icônes ont été redéfinies pour être plus modernes et cohérentes en essayant de suivre le concept de Adwaita adopté chez GNOME avec GNOME 3.

Dans le centre de configurations, les menus applications préférées et associations de fichiers ont fusionné pour configurer ces aspects en un seul endroit pour des raisons ergonomiques. Il permet aussi de configurer la mise à l'échelle de l'écran si votre écran le prend en charge.

Le navigateur de fichiers Thunar gère la mise en pause des opérations sur les fichiers et de gérer une file d'attente de ces opérations.

Pour les barres principales de l'interface, un nouveau plugin permet de gérer finement le bouton de status des applications, pour savoir si vous avez reçu un message dans votre logiciel de messagerie préféré par exemple.

Le menu À propos affiche plus d'informations concernant votre machine et Xfce, utile pour collecter des informations en cas de besoin.

GNOME-Nouvelle_vue_globale.png, avr. 2021

L'environnement de bureau minimaliste LxQt est proposé dans sa version 0.16.0.

Les préférences ont été particulièrement étendues, avec la possibilité de définir l'action à faire pour les boutons de mise en veille ou d'extinction de la machine. Il est possible d'y configurer la palette de couleurs de Qt. Elles permettent de définir un client de messagerie, un navigateur web et de fichiers par défaut.

Le visionneur d'images peut les redimensionner et afficher plus de formats différents.

Le serveur d'affichage Wayland est employé par défaut dans l'environnement KDE Plasma. Le support par KDE de Wayland est jugé suffisamment mature pour rejoindre GNOME dans ce choix par défaut, près de quatre ans et demi après. En cas de problèmes il reste toujours possible de lancer cet environnement avec X11. Évidemment, les applications non compatibles avec ce changement pourront être lancées de manière transparente à travers XWayland qui établie la couche de compatibilité entre les deux.

Rappelons que Wayland vise à améliorer la sécurité du système, en évitant quune application quelconque puisse dessiner sur dautres applications, par exemple. Il pourrait à terme améliorer les performances, en exploitant pleinement laccélération matérielle par les cartes graphiques. En outre, il devrait fiabiliser le système, en améliorant larchitecture du programme et en facilitant sa maintenance.

La mémoire d'échange zram activée peut utiliser toute la mémoire RAM et ce jusqu'à 8 Gio par défaut. Cette fonction introduite dans Fedora 33 était limitée au quart de la mémoire RAM de la machine et jusqu'à un maximum de 4 Gio. Cette extension a pour but de permettre l'exécution de certains programmes comme l'installateur de Fedora nommé Anaconda dans de bonnes conditions sur des machines qui ont 1 Gio de mémoire voire moins. Le choix initial pour Fedora 33 était aussi conservateur car il y avait des doutes sur le bon fonctionnement avec une zram pouvant remplir potentiellement la RAM entièrement, ce qui s'avère être peu réaliste en pratique.

Le gestionnaire de fenêtre minimaliste et pavant i3 dispose de sa propre image Spin de Fedora. C'est le premier gestionnaire de fenêtres pavant à bénéficier d'une image dédiée, ce qui peut faciliter la réalisation de tests de cet environnement. Il propose un environnement minimal pour des machines peu puissantes sans devoir passer par une autre édition de Fedora avant d'installer i3 par après.

L'audio va maintenant être géré par Pipewire par défaut, en remplacement de PulseAudio, ALSA et JACK. PulseAudio était globalement utilisé pour l'ensemble des applications classiques, ceux de GNOME ou Firefox par exemple, tandis que JACK pour les applications professionnelles ou usages avancés, comme pour faire de l'enregistrement audio de qualité, et ALSA pour des logiciels plus anciens qui ne se sont pas adaptés à PulseAudio. Ici Pipewire les remplace tous les trois et il fournit sa propre couche de compatibilité pour que la transition soit transparente.

Son avantage est que contrairement à PulseAudio, il est destiné à prendre en charge l'usage pointu des professionnels de l'audio dont la gestion d'une faible latence. Ces applications utilisaient JACK pour cette tâche, mais son intégration dans le système était souvent difficile et mauvaise ce qui rend la gestion du son globalement difficile.

Pipewire est également plus flexible que PulseAudio, plusieurs processus gèrent le graphe de routage du son et la configuration de ces flux. Par ailleurs il a été conçu avec la sécurité en tête, en étant capable de gérer les permissions de manière plus fines et de gérer les applications situées dans des conteneurs comme Flatpak. Il devient plus aisé d'interdire à une application d'enregistrer le son du micro par exemple.

Cependant, du moins pour Fedora 34, certaines fonctionnalités ne seront pas proposées par rapport à PulseAudio :

  • La découverte réseau via avahi et le transport réseau via les protocoles TCP et RTP ;
  • Définir sa machine comme serveur multimédia UPNP.

Cela sera proposé par la suite, si jamais vous souhaitez revenir à PulseAudio ou JACK comme avant cela reste possible via les commandes suivantes :

# dnf swap --allowerasing pipewire-pulseaudio pulseaudio 
# dnf swap --allowerasing pipewire-jack-audio-connection-kit jack-audio-connection-kit 

L'image Comp Neuro pour la neuroscience va être déclinée aussi en image Docker / podman pour la fournir sous forme de conteneurs. Cela facilitera sa diffusion et son usage à partir d'un autre système hôte.

Les images netinstall et DVD n'auront plus le fichier ext4 à l'intérieur du système de fichiers squashfs. Squashfs récupère larborescence complète de l'image d'installation. Jusqu'à présent le système complet était effectivement dans une partition de type ext4, lui même inclus dans le système de fichiers squashfs qui est en lecture seule et compressée pour optimiser sa taille. Ext4 était nécessaire pour bénéficier des attributs de fichiers étendus XATTRs et parce qu'il fallait être capable de monter ce système de fichier en lecture et écriture durant le démarrage, ce que squashfs ne gère pas. Mais squashfs sait maintenant prendre en charge les attributs XATTRs, et via un système de fichiers overlayfs par dessus on peut contourner sa limitation concernant la lecture / écriture. Se débarrasser de la partition ext4 permet de rendre la compression par squashfs plus efficace, car on supprime une couche intermédiaire inefficace dans ce processus, mais aussi de simplifier la réalisation et le test de l'image. Les images concernées gagnent environ 27 Mio.

GNOME-A_propos.png, avr. 2021

Gestion du matériel

La configuration de GRUB est unifiée pour toutes les architectures. En particulier entre les architectures utilisant l'EFI d'un côté comme x86_64 ou certaines machines ARM et x86 avec BIOS ou PowerPC 64 bits avec OpenFirmware de l'autre. En effet, avec l'EFI, la configuration comme l'environnement de GRUB sont situés dans la partition dédiée de l'EFI quand pour les autres cela réside dans la partition ou le répertoire /boot.

En particulier cela signifie que le chemin d'accès au fichier de configuration diffère, avec l'EFI c'est le fichier /boot/efi/EFI/fedora/grub.cfg quand c'est /boot/grub2/grub.cfg pour les autres. Cela signifie que les outils qui gèrent ces configurations et leur installation comme les utilisateurs et la documentation doivent en être conscients. Par ailleurs, en cas de désactivation de l'EFI ou de transfert du disque dur sur une autre machine, le démarrage peut ne plus fonctionner.

La solution est de sauvegarder les fichiers grub.cfg et grubenv dans /boot/grub2/. Le contenu de /boot/efi/EFI/fedora/grub.cfg deviendra très minimal pour définir la variable $prefix qui permettra de définir sa localisation dans le système via UUID de la partition contenant le répertoire /boot. L'inconvénient est que cette disposition oblige GRUB à être installé dans le répertoire /boot mais comme c'est déjà le cas pour le noyau dans Fedora, finalement cela ne change pas grand chose. Il sera toujours difficile de réaliser un démarrage ne reposant que sur l'EFI.

L'architecture ARMv7 va bénéficier de l'UEFI par défaut pour les nouvelles images générées par le projet Fedora. GRUB devient de fait le nouveau gestionnaire de démarrage par défaut au lieu de extlinux. Cela rendra l'installation, la documentation et la maintenance de Fedora plus uniforme au sein des architectures avec un seul chargeur de démarrage par défaut.

Une nouvelle image pour l'architecture AArch64 sera proposée avec l'environnement KDE Plasma. Cette image rejoint les images Workstation, Xfce, Minimal et Server pour cette architecture, avec un choix de fait plus large.

Les fichiers firmware du noyau sont compressés avec l'algorithme LZMA2. Cette nouvelle possibilité offerte par Linux 5.3 consiste à compresser en somme les fichiers contenus dans le répertoire /usr/lib/firmware/. Avec le temps le contenu du dépôt linux-firmware pèse plus de 900 Mio, et ce sans compter les firmware provenant d'autres endroits. Avec la compression il devient possible de réduire cet impact maximal par deux. En contrepartie ces fichiers sont décompressés à la volée quand ils sont chargés ce qui ajoute une petite latence supplémentaire.

Internationalisation

Un nouveau site web et son infrastructure est proposé pour fournir les statistiques de traduction de Fedora et simplifier la maintenance des mémoires de traduction. L'un des objectif est tout d'abord de mesurer pour connaître la situation de la traduction dans Fedora, que ce soit les projets liés à Fedora comme les paquets qu'elle distribue. Le nombre de langues traduites, et le taux de traduction pour chacune avec des détails par projet. Cela permettra de facilement rediriger quelqu'un vers la bonne plateforme de traduction, par exemple si vous souhaitez améliorer la traduction du paquet 0ad en français, le site vous indique que l'équipe de traduction correspondante est située là bas : http://www.transifex.com/wildfire-games/0ad/language/fr/

Mais cela permet aussi de travailler la mémoire de traduction de manière plus transversale pour renforcer la cohérence d'ensemble. Un même terme peut être traduit de plusieurs façons différentes, sans qu'il y ait spécialement un bon ou un mauvais choix. La mémoire de traduction est d'identifier comment ces mots ont été traduits par le passé, pour essayer d'utiliser toujours le même terme. Au sein du Logiciel Libre, chaque projet gère sa traduction de son côté, la traduction de Firefox est totalement isolée de celle de LibreOffice. Mais pourtant ils traduisent des mots en commun, et font des choix chacun de leur côté, avec une mémoire de traduction plus centralisée ces projets pourraient éventuellement adopter les mêmes choix et apporter une plus grande cohérence dans leurs interfaces dans cette langue.

Les projets Debian et Ubuntu ont ce genre de site web. Dans le cas de Debian il est trop spécifique à cette distribution avec des outils très anciens ne tirant pas profit des progrès réalisés ces 20 dernières années dans le domaine de la traduction. Et typiquement ils ne proposent rien concernant la mémoire de traduction. Alors que Ubuntu cela est trop lié à l'outil launchpad, et la limite entre ce qui est fait par eux et par les projets en amont n'est pas bien définie.

Ce travail repose sur l'analyse des paquets source RPM pour extraire les fichiers de traduction en format .po pour les analyser et les traiter.

IBus est proposé à la version 1.5.24. Cette version propose la prise en charge de la nouvelle version de la bibliothèque graphique GTK4. Par ailleurs l'utilitaire ibus-setup dispose d'une meilleure recherche pour les méthodes d'entrées.

ibus-anthy est le système d'entrée par défaut pour le japonais au lieu de ibus-kkc, ibus-m17n pour le singhalais au lieu de ibus-sayura et ibus-unikey pour le vietnamien au lieu de ibus-bogo. Ces changements ont eu lieu car ces projets n'étaient plus effectivement maintenus, avec de vieux bogues non résolus, la non prise en charge des dernières fonctionnalités d'Ibus ou un mauvais support de Wayland.

HarfBuzz est activé par défaut dans les polices FreeTypes pour permettre d'améliorer le rendu dans les langues ayant des symboles plus complexes.

kasumi-unicode est généré à partir du fichier source kasumi.spec dorénavant. Les dictionnaires utilisateurs sont maintenant sauvegardés dans le répertoire définis par $XDG_CONFIG_HOME. Et il est mieux maintenu que anthy dont il dérive indirectement.

GNOME-Liste_des_applications.png, avr. 2021

Administration système

Par défaut les partitions btrfs créées lors de l'installation auront la compression du système de fichiers activée avec l'algorithme zstd. Cet algorithme a pour avantage de présenter un beau ratio de compression tout en étant rapide à la compression comme la décompression, caractéristiques idéales pour cet usage.

Cette fonctionnalité repose sur la capacité de btrfs de faire de la compression par fichier à la volée de manière transparente, zstd étant l'un des trois algorithme officiellement pris en charge. L'objectif est de réduire l'usage de l'espace de stockage tout comme d'augmenter potentiellement la durée de vie des SSD (ou eMMC) qui sont de plus en plus courants. Les performances en lecture comme écriture peuvent également être améliorées ou dégradées suivant la configuration.

SELinux ne peut plus être entièrement désactivé après le démarrage du système. Seul le passage entre les modes permissif et strict est permis après ce stade. Un redémarrage devient nécessaire pour appliquer une désactivation complète. L'objectif derrière est d'améliorer la sécurité du noyau, une partie des structures de données peuvent passer en mode lecture seule après l'initialisation pour éviter tout changement non souhaitable après l'initialisation. Le noyau Linux ayant décidé de suivre cette direction, le maintient de cette fonctionnalité serait à charge du projet Fedora ce qui n'est pas souhaitable.

Si vous souhaitez désactiver entièrement SELinux sur votre système, cela passe donc par l'argument selinux=0 à passer au noyau.

En parlant de SELinux, il a été mis à jour pour prendre en compte des dernières classes, permissions et capacités ajoutées dans le noyau. En particulier les éléments suivants sont dorénavant gérés :

  • Nouvelles classes : lockdown et perf_event ;
  • Nouvelles permissions : watch watch_mount watch_reads watch_sb et watch_with_perm ;
  • Nouvelles capacités : bpf checkpoint_restore et perfmon.

Cela permet entre autre d'améliorer la granularité des permissions et autorisations du système. L'autre intérêt est de permettre aux systèmes utilisant la fonctionnalité Multi-level Security de démarrer. Car une telle politique de sécurité peut bloquer le démarrage si des permissions inconnues sont détectées.

La gestion du manque de mémoire disponible sera prise en charge par le service systemd-oomd par défaut. systemd-oomd se base sur les informations du noyau à propos de la pression mémoire d'une part, mais aussi sur le temps perdu par les différents cgroups. Le temps passé à réclamer des pages mémoires libres, des erreurs mémoires liées au cache ou récupérer des données depuis le swap plutôt que la RAM. Ces informations sont des indices d'une forte pression mémoire sur le système. En cas de dépassements de certains seuils, configurables, il peut décider sur quel processus agir qui sera par défaut celui qui demande le plus de nouvelles pages mémoires et pas celui qui en a le plus. Il est d'ailleurs possible de définir dans une unité systemd de diminuer la priorité dans la sélection du processus à tuer voire que systemd l'ignore complètement. Cela se fait respectivement via les options ManagedOOMPreference=avoid et ManagedOOMPreference=omit. Cela peut servir pour s'assurer que certains processus critiques ne seront jamais (ou peu souvent) tués dans ces conditions.

Pour revenir à earlyoom utilisé jusque là, vous pouvez exécuter les commandes suivantes :

# systemctl disable --now systemd-oomd
# systemctl enable --now earlyoom

Les paramètres de démarrage, reçus par le noyau Linux, à destination de l'installateur Anaconda devront être préfixés avec inst. pour éviter les conflits. En effet il est possible d'utiliser les paramètres envoyés au noyau pour qu'Anaconda qui est l'installateur de Fedora puisse se comporter différemment. Cependant jusqu'ici pour les variables supportées le préfixe n'était pas obligatoire, il était possible donc d'envoyer debug ou inst.debug pour qu'il soit plus bavard en cas de problèmes. Sauf que sans le préfixe, le noyau utilise cette variable aussi pour sortir plus d'informations à l'exécution, ce qui n'est probablement pas voulu par l'utilisateur.

Comme pour Dracut qui a le préfixe rd. dans ce cas, inst. devient nécessaire pour Anaconda pour éviter tout conflit d'usage avec le noyau ou d'autres outils.

Les services systemd qui doivent être relancés suite à une mise à jour le seront tous à la fin de la procédure. Jusqu'ici quand un service était mis à jour, via un script avec une instruction %post , RPM pouvait relancer automatiquement le service lors de la mise à niveau du paquet. Dorénavant, un paquet qui a un tel service à relancer devra fournir un fichier spécifique sous la forme /usr/lib/systemd/system/<service>.service.d/needs-restart.conf ou alors une instruction dans le fichier .service directement sous la forme X-restart-on-upgrade=true|false.

Ainsi, le gestionnaire de paquets peut relancer tous les services nécessaires quand la mise à niveau est totalement finie. Et les administrateurs systèmes pourront aussi éventuellement affiner ce choix selon leurs besoins. L'intérêt est que cela garantie que le relancement des services se fait bien une fois que toutes les dépendances nécessaires ont bien été mises à jour au préalables ce qui évite des bogues un peu difficile à identifier et à corriger.

GNOME-Web_onglets.png, avr. 2021

Les utilitaires Bluetooth désuets ciptool, gatttool, hciattach, hciconfig, hcidump, hcitool, rfcomm et sdptool sont déplacés dans le paquet bluez-deprecated avant une suppression dans le futur. Ces paquets ont globalement été abandonnés par le projet bluez au profit de la commande bluetoothctl.

La collection d'outils X.org sera proposée via des paquets plus individuels que les paquets génériques xorg-x11-{apps,font-utils,resutils,server-utils,utils,xkb-utils} employés jusqu'ici. Certains utilitaires sont également supprimés. Ces collections d'utilitaires étaient assez historiques mais offrent peu de flexibilité et ne représentent plus la réalité. Par exemple les utilitaires luit ou edid-decode ne sont même plus développés sous l'égide de X.org. Le versionnage de ces paquets ne collait plus avec ceux des projets embarqués. Mettre à jour un paquet pour un composant nécessitait de régénérer cette mise à jour pour l'ensemble. Les paquets étaient aussi plus gros que nécessaires pour beaucoup d'utilisateurs. Tout ceci est donc simplifié et plus cohérent avec le nouveau découpage.

Les paquets xemacs, xemacs-packages-base, xemacs-packages-extra, neXtaw, nscd et python-mock sont en passe de subir le même sort. XEmacs n'a pas eu de nouvelles version depuis près de 7 ans et repose sur une bibliothèque neXtaw qui n'en a pas eu depuis 2003. Pour ncsd il n'évolue plus trop également, avec une grande dette technique et est remplacé par défaut par systemd-resolved et sssd depuis quelques temps. Enfin pour python-mock, il a intégré la bibliothèque standard de Python sous le nom de module unittest.mock et n'est dès lors plus nécessaire avec les versions récentes de Python.

XWayland est proposé dans un paquet à part et indépendant du reste de X.org : xorg-x11-server-Xwayland. XWayland évolue plus vite que X11, cela permet à Fedora de produire des mises à jour de ce premier plus souvent en se basant sur des versions non stables. Le tout en évitant de maintenir des correctifs au sein de Fedora pour exploiter le travail du projet officiel directement. Cela permet aussi d'avoir plusieurs images de travail par fenêtres. Permettant de modifier l'affichage de la fenêtre en fond, sans modifier à l'écran son affichage, puis quand le rendu est terminé faire le changement instantannément, réduisant les artefacts graphiques.

Le célèbre serveur de DNS Bind est lié à la version 9.16. Le principal changement est la prise en charge de DNSSEC pour effectuer des requêtes DNS chiffrées et donc plus sécurisées. Certains outils associés comme dig, mdig et delv peuvent exporter des données en format yaml.

Le gestionnaire de base de données PostgreSQL s'impose avec sa version 13. Cette version apporte entre autre la déduplication des entrées de l'index de l'arbre B-tree, ce qui diminue les besoins en espace de stockage et augmente les performances. Les requêtes qui exploitent des aggrégats ou des tables partitionnées sont également plus performantes. Les requêtes de manière générales sont réordonnées en se basant sur des statistiques pour améliorer le temps de traitement.

Son concurrent MariaDB est proposé à la version 10.5. Parmi les changements, il y a le renommage des commandes qui débutaient encore avec mysql par mariadb avec un lien symbolique de l'ancien vers le nouveau nom, histoire d'achever la transition. Il a un nouveau type de données INET6 pour gérer les IPv6. Les privilèges sont gérés plus finement, le privilège SUPER est ainsi découplé en une dizaines de nouveaux privilèges. Enfin la partie base de données n'est pas en reste, InnoDB bénéficie lui aussi d'améliorations de performances très diverses.

L'utilitaire de gestion du stockage Stratis dispose de la version 2.3.0. Depuis la précédente version, les systèmes de fichiers qu'il gère sont situés dans le répertoire /dev/stratis. L'interface D-bus a été étendue, l'utilisateur peut aussi changer son niveau de détails des journaux.

Le démon pour synchroniser le temps avec le protocole NTP et nommé sobrement ntp utilise ntpsec à la place. Mais chrony reste le démon utilisé par défaut pour cette fonction. ntp est effectivement peu maintenu et a de gros soucis de sécurité qui ne sont pas corrigés. ntpsec dérive de celui-ci, et comme l'indique son nom se concentre sur la sécurité justement. Cependant toutes les fonctionnalités ne sont pas encore implémentées, mais c'est suffisant pour l'essentiel des besoins.

XFCE-Bureau.png, avr. 2021

Développement

Mise à jour de la suite de compilateurs libre GCC 11. La compilation C utilise par défaut le standard C17 au lieu de C14. Il prend en charge le Linux Kernel Concurrency Sanitizer pour détecter à l'exécution des problèmes de concurrence au sein du noyau. En cas d'erreurs, GCC renvoie le numéro de colonnes réel depuis le début de la ligne et non plus en nombre d'octets, ce qui posait des problèmes avec les caractères occupants plusieurs octets (cas avec l'encodage UTF-8) ou un caractère qui est affiché sur plusieurs colonnes comme les emoji. La prise en charge des fonctionnalités de C2X et de C20 progresse, et de nombreux nouveaux avertissements sont aussi disponibles pour ces langages.

Son concurrent LLVM passe lui à la version 12. La version 11 reste disponible dans les dépôts pour les paquets qui en ont besoin. Il prend en charge des optimisations pour les processeurs récemment sortis, et suit la convention de GCC pour définir les micro architectures x86-64-v234 pour définir leurs niveaux de fonctionnalités. Concernant C, la prise en charge du langage C20 a été améliorée, avec le début du travail pour le futur C++2b. L'outil clangd consomme également moins de RAM de manière significative.

Tandis que la bibliothèque C Glibc passe à la version 2.33. La prise en charge du matériel s'améliore avec l'architecture RISC-V 32 bits. Il est possible via l'en-tête <sys/platform/x86.h> d'obtenir des macros pour connaître les fonctionnalités du processeur x86. Et beaucoup de corrections de bogues et de failles de sécurité.

Mise à jour des utilitaires binutils 2.35. Son assembleur peut produire des numéros de ligne des tables au format DWARF-5. La commande readelf fait également plus de vérifications à la lecture des fichiers d'entrées. Puis aussi les corrections de bogues usuels.

Le petit coup d'accélération pour la bibliothèque généraliste C++ Boost 1.75. Depuis Fedora 33, la bibliothèque Boost propose de nouveaux modules :

  • STLInterfaces pour simplifier l'écriture d'itérateurs, conteneurs et vues compatibles avec la bibliothèque standard ;
  • PFR 2.0 qui fournit une réflexion basique, donc obtenir les éléments d'une structure par index par exemple et itérer dessus par exemple en C++14 et supérieurs ;
  • JSON pour interpréter, sérialiser un document JSON et manipulations de DOM en C++11 et ultérieur ;
  • LEAF pour simplifier la gestion d'erreur de manière légère compatible C++11 et ultérieur également.

Et bien sûr beaucoup de correctifs ont été apportés depuis aussi.

Le langage Go fait un bon en avant avec la version 1.16. Grâce au nouveau module embed, il est possible de définir via l'instruction //go:embed l'inclusion d'un fichier dans le binaire directement. La variable environnement GOVCS permet de restreindre les gestionnaires de version à employer pour les téléchargements pour des raisons de sécurité. L'édition de liens consomme moins de mémoire et est en moyenne 25% plus rapide.

Le langage précieux Ruby est proposé dans sa nouvelle version 3.0. Ce langage débute par une amélioration significative de ses performances avec son compilateur à la volée MJIT, de l'ordre de trois fois plus performant que Ruby 2.0. Un nouveau langage RBS est fourni pour définir les types dans Ruby, pour permettre aux différents outils de profilage de mieux interpréter les programmes Ruby. Un nouveau module expérimental arrive, avec Ractor pour fournir une exécution dans un fil d'exécution parallèle sans partage d'objet, la communication se faisant par messages pour améliorer la fiabilité. Et bien d'autres changements encore.

Sa boîte à outils Ruby on Rails arrive à la gare au quai 6.1. Il permet d'avoir un changement de connexion par base de données, passer au rôle reading ne se fait plus que sur une base de données à la fois, et non toutes les connexions. Pour les bases de données encore, il prend en charge le schéma unique pour de multiples partitions. Et bien d'autres choses à découvrir.

L'environnement de compilation de binaires Windows, MinGW, est mis à jour et fourni GCC 11, GDB 10 et binutils 2.36. Cela permet d'utiliser les mêmes versions de ces composants que pour une compilation native pour Fedora.

La bibliothèque de sécurité NSS avec sa version 3.52 a changé la structure CK_GCM_PARAMS en étant incompatible en terme de source code, mais pas son interface binaire. Cela est dû au changement dans la spécification dans PKCS #11 v3.0, la version précédente n'était pas conforme.

OpenLDAP va fournir uniquement des bibliothèques avec un fil d'exécution parallèle. Des liens symboliques redirigent la liaison vers la bibliothèque libldap vers libldap_r. Cela suit la décision du projet officiel pour sa prochaine version majeure, la différence entre les deux bibliothèques résidant uniquement sur cette faculté d'exploiter un ou plusieurs cœurs. Mais comme elles partageaient les mêmes symboles, le comportement pouvait être imprévisible lors de la compilation, pouvant choisir l'un ou l'autre.

Les bibliothèques Rust fournis via les crates nécessaires pour les paquets proposés par Fedora seront fournies dans les dépôts dans des paquets dédiés sous la forme rust-$NOM_CRATE comme par exemple rust-libsqlite3-sys pour la bibliothèque SQLite. Cela permettra notamment de mieux mutualiser les ressources pour compiler les paquets de Fedora, un crate pouvant être utilisé par plusieurs paquets. Cela réduit également le besoin d'effectuer des étapes manuelles pour compiler de tels projets.

Les bibliothèques Python avec un nom de fichier dépendant de l'architecture utilisent maintenant la nomenclature officielle de CPython au lieu d'un nom spécifique à Fedora. Par exemple le fichier /usr/lib64/python3.9/lib-dynload/array.cpython-39-powerpc64le-linux-gnu.so devient /usr/lib64/python3.9/lib-dynload/array.cpython-39-ppc64le-linux-gnu.so. Cela concerne surtout les architectures ppc64le et armv7hl, Fedora avait fait des choix à l'époque où ces architectures n'étaient pas gérées d'où ce conflit apparu progressivement. Cela permettra de résoudre certains problèmes que pouvaient rencontrer des développeurs sur de telles architectures.

Les paquets ne fournissant qu'une bibliothèque Nodejs ne seront plus proposés. Le but de Fedora est de ne fournir que les paquets permettant de fournir l'interpréteur, les outils annexes tels que npm, les en-têtes de base et les différents binaires finaux reposant sur Nodejs. L'objectif est de réduire le nombre de paquets avec l'effort de maintenance que cela nécessite. Chaque paquet pourra ainsi utiliser la version de la bibliothèque qui correspondra à celui testé et approuvé par le logiciel d'origine. Il y avait d'ailleurs quelques problèmes pour désinstaller ces paquets spécifiquement qui seront de fait résolus ainsi.

GNOME-Meteo.png, avr. 2021

Projet Fedora

Le système minimal de compilation du projet Fedora, buildroot, se débarrasse de make. Sur les 22 309 paquets compilés par Fedora, environ 11 931 d'entre eux soit la moitié n'ont pas besoin de cet outil pour être générés. En se séparant de lui par défaut, l'image est un peu plus petite ce qui réduit les coûts d'exploitation en bande passante, taille d'image et espace disque consommé.

Les macros liés à Python 2 pour créer les paquets RPM sont gelés. Ceux pour générés les dépendances automatiques liés à Python 2 sont supprimés car plus nécessaires suite au passage à Python 3 l'an dernier. Cet effort de maintenance n'est plus justifié pour les 13 paquets qui nécessitent encore Python 2 à l'heure actuelle.

L'utilitaire fbrnch est proposé dans les dépôts. Cet outil, venant du nom Fed Brunch, simplifie le workflow en automatisant certaines étapes pour les empaqueteurs du projet. Créé l'année dernière, ayant reçu des retours favorables il peut passer de son dépôt Copr non officiel à une disponibilité plus générale ce qui augmentera son usage et son évolution.

Les dépôts git de Fedora ont renommé la branche principale en main au lieu de master. L'objectif est de suivre la politique de nombreux projets libres qui ont fait ce changement par le passé comme git lui même. Abandonnant une terminologie qui peut poser problèmes alors que des équivalents existent, il a été décidé d'effectuer ce changement pour être plus ouvert à l'ensemble des contributeurs potentiels.

La politique concernant les modules a été remaniée et formalisée. L'objectif est de définir ce qui est possible de faire ou pas avec les modules pour éviter la cacophonie suivant les empaqueteurs. Notamment concernant la gestion des conflits entre les versions, ou avec d'autres paquets. La branche par défaut d'un module ne doit pas dépendre d'un autre module dans une version qui n'est pas celle par défaut. Il n'est pas possible de changer cette branche de référence pour une version de Fedora donnée, seule Rawhide ou un changement de version de Fedora peut permettre un tel changement. De même un paquet non modulaire ne peut pas devenir modulaire en cours de route pour une version donnée de Fedora.

La communauté francophone

L'association

Logo.png, oct. 2017

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

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.

L'équipe se réunit tous les lundis soir après 21h (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 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 34 ?

Mediawriter.png, oct. 2018

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

Fedora 34 Beta est de sortie

Charles-Antoine Couret

En ce mardi 23 mars, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta Fedora 34.

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

La version finale est pour le moment fixée pour le 20 ou 27 avril. Voici les nouveautés annoncées pour cette version :

Expérience utilisateur

  • Passage à GNOME 40.
  • L'environnement de bureau Xfce fait tourner la roue vers sa version 4.16.
  • L'environnement de bureau minimaliste LxQt est proposé dans sa version 0.16.0.
  • Le serveur d'affichage Wayland est employé par défaut dans l'environnement KDE Plasma.
  • La mémoire d'échange zram peut utiliser toute la mémoire RAM et ce jusqu'à 8 Gio par défaut. Auparavant c'était limité au quart de la mémoire RAM de la machine et jusqu'à un maximum de 4 Gio.
  • Le gestionnaire de fenêtre minimaliste et pavant i3 dispose de sa propre image Spin de Fedora.
  • L'audio va maintenant être géré par Pipewire par défaut, en remplacement de PulseAudio, ALSA et JACK.
  • L'image Comp Neuro pour la neuroscience va être déclinée aussi en image Docker / podman pour le fournir sous forme de conteneurs.
  • Les images netinstall et DVD n'auront plus le fichier ext4 à l'intérieur du système de fichiers squashfs. Squashfs récupère larborescence complète de l'image d'installation.

Gestion du matériel

  • La configuration de GRUB est unifiée pour toutes les architectures. En particulier entre les architectures utilisant l'EFI d'un côté comme x86_64 ou certaines machines ARM et x86 avec BIOS ou PowerPC 64 bits de l'autre.
  • L'architecture ARMv7 va bénéficier de l'UEFI par défaut pour les nouvelles images générées par le projet Fedora. GRUB devient de fait le nouveau gestionnaire de démarrage par défaut au lieu de extlinux.
  • Une nouvelle image pour l'architecture AArch64 sera proposée avec l'environnement KDE Plasma.
  • Les fichiers firmware du noyau sont compressés avec l'algorithme LZMA2.

Internationalisation

  • Un nouveau site web et son infrastructure va être proposé pour fournir les statistiques de traduction de Fedora et simplifier la maintenance des mémoires de traduction.
  • IBus est proposé à la version 1.5.24.
  • ibus-anthy est le système d'entrée par défaut pour le japonais, ibus-m17n pour le singhalais et ibus-unikey pour le vietnamien.
  • HarfBuzz est activé par défaut dans les polices FreeTypes pour permettre d'améliorer le rendu dans les langues ayant des symboles plus complexes.
  • kasumi-unicode est généré à partir du fichier source katsumi.spec dorénavant.

Administration système

  • Par défaut les partitions btrfs crées lors de l'installation auront la compression du système de fichiers activée avec l'algorithme zstd.
  • SELinux ne peut plus être entièrement désactivé après le démarrage. Seul le passage entre les modes permissif et enforcé est permis. Un redémarrage est nécessaire pour appliquer une désactivation complète.
  • SELinux a été mis à jour pour prendre en compte des dernières classes, permissions et capacités ajoutées dans le noyau.
  • La gestion du manque de mémoire disponible sera prise en charge par le service systemd-oomd par défaut. Pour revenir à earlyoom utilisé jusque là, vous pouvez exécuter les commandes suivantes :
# systemctl disable --now systemd-oomd

# systemctl enable --now earlyoom
  • Les paramètres de démarrage, reçus par le noyau Linux, à destination de l'installateur Anaconda devront être préfixés de inst. pour éviter les conflits. Sinon ils sont ignorés.
  • Les services systemd qui doivent être relancées suite à une mise à jour le seront toutes à la fin de la procédure.
  • Les utilitaires Bluetooth désuets ciptool, gatttool, hciattach, hciconfig, hcidump, hcitool, rfcomm et sdptool sont déplacés dans le paquet bluez-deprecated avant une suppression dans le future.
  • La collection d'outils X.org sera proposée via des paquets plus individuels que les paquets génériques xorg-x11-{apps,font-utils,resutils,server-utils,utils,xkb-utils} employés jusqu'ici. Certains utilitaires sont également supprimés.
  • Les paquets xemacs, xemacs-packages-base, xemacs-packages-extra, neXtaw, nscd et python-mock sont en passe de subir le même sort.
  • XWayland est proposé dans un paquet à part et indépendant du reste de X.org : xorg-x11-server-Xwayland.
  • Le célèbre serveur de DNS Bind est lié à la version 9.16.
  • Le gestionnaire de base de données PostgreSQL s'impose avec sa version 13.
  • Son concurrent MariaDB est proposé à la version 10.5.
  • L'utilitaire de gestion du stockage Stratis dispose de la version 2.3.0.
  • Le démon pour synchroniser le temps avec le potocole NTP et nommé sobrement ntp utilise ntpsec à la place. Mais chrony reste le démon utilisé par défaut pour cette fonction.

Développement

  • Mise à jour de la suite de compilateurs libre GCC 11.
  • Son concurrent LLVM passe lui à la version 12.
  • Tandis que la bibliothèque C Glibc passe à la version 2.33.
  • Mise à jour des utilitaires binutils 2.35.
  • Le petit coup d'accélération pour la bibliothèque généraliste C++ Boost 1.75.
  • Le langage Go fait un bon en avant avec la version 1.16.
  • Le langage précieux Ruby est proposé dans sa nouvelle version 3.0.
  • Sa boîte à outils Ruby on Rails arrive à la gare au quai 6.1.
  • L'environnement de compilation de binaires Windows, MinGW, est mis à jour qui fourni GCC 11, GDB 10 et binutils 2.36.
  • La bibliothèque de sécurité NSS avec sa version 3.52 a changé la structure CK_GCM_PARAMS en étant incompatible en terme de source code, mais pas son interface binaire.
  • OpenLDAP va fournir uniquement des bibliothèques avec un fil d'exécution parallèle. Des liens symboliques redirigent la liaison vers la bibliothèque libldap vers libldap_r.
  • Les bibliothèques Rust fournis via les crate nécessaires pour les paquets proposés par Fedora seront fournis dans les dépôts dans des paquets dédiés sous la forme rust-$NOM_CRATE comme par exemple rust-libsqlite3-sys pour la bibliothèque SQLite.
  • Les bibliothèques Python avec un nom de fichier dépendant de l'architecture utilisent maintenant la nomenclature officielle de CPython au lieu d'un nom spécifique à Fedora.
  • Les paquets ne fournissant qu'une bibliothèque Nodejs sans être utilisée en tant que dépendance ne seront plus proposés.

Projet Fedora

  • Le système minimal de compilation du projet Fedora, buildroot, se débarrasse de make.
  • Les macros liés à Python 2 pour créer les paquets RPM sont gelés. Ceux pour générés les dépendances automatiques liés à Python 2 sont supprimés car plus nécessaires suite au passage à Python 3 l'an dernier.
  • L'utilitaire fbrnch est proposé dans les dépôts.
  • Les dépôts git de Fedora ont renommé la branche principale en main au lieu de master.
  • La politique concernant les modules a été remaniée et formalisée.

Tester

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

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

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

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

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

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

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate.

Bons tests à tous !

AMC version 1.4.0 Fedora 33

Patrice Kadionik

Les RPM d'AMC (Auto Multiple Choice) version 1.4.0 pour Fedora 33 sont disponibles dans le dépôt eddy33.


Installation :

$ sudo dnf install perl-Gtk3 perl-Clone
$ sudo dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/eddy33-release-33.rpm
$ sudo dnf install auto-multiple-choice
Attention. AMC utilise openCV. Fedora 33 est basé sur openCV 4.3 qui nécessite le support par le processeur de l'extension AVX2.

++

Fedora 33 vs Fedora 32 : comparaison des performances pour les versions 64 bits

Patrice Kadionik

Salut.

Voici les résultats comparatifs de Fedora 33 vs Fedora 32.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 33 version 64 bits avec le noyau Fedora 5.9.14-200.fc33.x86_64.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 33 et exécuté sous Fedora 33 (5.9.14-200.fc33.x86_64).
  • 10 séries de tests avec UnixBench compilé sous Fedora 32 et exécuté sous Fedora 32 (5.6.6-300.fc32.x86_64).
Voici les résultats obtenus :

Fedora 33 version 64 bits :

Série 1 : 695.5
Série 2 : 699.9
Série 3 : 714.6
Série 4 : 711.5
Série 5 : 714.1
Série 6 : 605.6
Série 7 : 683.1
Série 8 : 695.9
Série 9 : 707.2
Série 10 : 697.6

Moyenne : 692,5

Fedora 32 version 64 bits :

Voici pour rappel les résultats obtenus avec Fedora 32 :
Série 1 : 672.0
Série 2 : 680.7
Série 3 : 671.5
Série 4 : 687.4
Série 5 : 681.9
Série 6 : 675.2
Série 7 : 670.2
Série 8 : 688.8
Série 9 : 679.6
Série 10 : 682.9

Moyenne : 679.0

Résultats :

Pour Fedora 33, on obtient un indice moyen de 692,5 pour UnixBench.
Pour Fedora 32, j'avais obtenu un indice moyen de 679.0 pour UnixBench.


On a donc une petite hausse de 2,0 % de Fedora 33 64 bits par rapport à Fedora 32 64 bits :

perfs_fedora_F33.png

Conclusion :

Au moment de ces tests, le noyau Fedora 33 (basé sur le noyau vanilla 5.9.14) est un peu plus performant de près de 2 % que le noyau Fedora 32 (basé sur le noyau vanilla  5.6.6). On retrouve la fluctuation habituelle peu significative par rapport aux précédents tests.

++

Résultats des élections de Fedora 12/20

Charles-Antoine Couret

Comme je vous le rapportais il y a peu, Fedora a organisé des élections pour renouveler partiellement le collège de ses organes FESCo, Mindshare et Council.

Le scrutin est comme toujours un vote par valeurs. Nous pouvons attribuer à chaque candidat un certain nombre de points, dont la valeur maximale est celui du nombre de candidat, et le minimum 0. Cela permet de montrer l'approbation à un candidat et la désapprobation d'un autre sans ambiguïté. Rien n'empêchant de voter pour deux candidats avec la même valeur.

Les résultats pour le Conseil sont :

  # votes |  noms
  - --------+----------------------
  358           Tom Callaway
  - --------+----------------------
  181           Till Maas

À titre indicatif le score maximal possible était de 216 * 2 votes soit 432 votes.

Les résultats pour le FESCo sont (seuls les cinq premiers sont élus) :

  # votes |  noms
- --------+----------------------
  886   Miro Hrončok 
  878        Kevin Fenzi
  724   Zbigniew Jędrzejewski-Szmek
  681   Fabio Valentini
  591   David Cantrell
- --------+----------------------
  536   Dan Čermák

À titre indicatif le score maximal possible était de 216 * 6 soit 1296.

Les résultats pour le Mindshare sont donc :

     # votes |  noms
     - --------+----------------------
     263        Till Maas
     - --------+----------------------
     221        Nasir Hussain

À titre indicatif le score maximal possible était de 202 * 2 soit 404.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin avec un réel enjeu était proche aux alentours de 275-250 votants ce qui est un peu en deçà de l'édition précédente. Les scores sont aussi plutôt éparpillés.

Bravo aux participants et aux élus et le meilleur pour le projet Fedora.

12/20 Élections pour le Conseil, FESCo et Mindshare pendant encore quelques jours

Charles-Antoine Couret

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au vendredi 4 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Par ailleurs, comme pour le choix des fonds d'écran additionnel, vous pouvez récupérer un badge si vous cliquez sur un lien depuis l'interface après avoir participé à un vote.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège. Ici 5 places sont à remplacer.

Mindshare

Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

  • La communication entre les équipes, notamment entre la technique et le marketing ;
  • Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
  • Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
  • Gestion de l'équipe marketing.

Il y a 9 membres pour gérer ce comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.

Fin de vie de Fedora 31

Charles-Antoine Couret

C'est en ce mardi 24 novembre 2020 que Fedora 31 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 33, la version n-2 (donc Fedora 31) est déclarée comme en fin de vie.

Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 31 et antérieurs d'effectuer la mise à niveau vers Fedora 33 ou 32.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 32 ou 33. N'hésitez pas à lancer la mise à niveau par ce biais.