Sortie de Fedora Linux 35 Beta

Posté par  (site Web personnel) . Édité par ted et Ysabeau. Modéré par Ysabeau. Licence CC By‑SA.
Étiquettes :
31
28
sept.
2021
Fedora

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é d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 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.

Sommaire

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, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.

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

Les tests à effectuer et les rapports sont à faire via la page suivante : http://testdays.fedorainfracloud.org/events. 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 Linux 35.

Bons tests à tous et à toutes !

Aller plus loin

  • # Frileux

    Posté par  . Évalué à 1.

    Utilisateur de Linux depuis 1999, je suis sous fedora que depuis la 32.
    En voulant tester comme le souhaite les développeurs, j'ai fait la 33 bêta, puis en voulant tester la 34 bêta, j'ai eu un crash monumental en pleine maj… Autant dire que ça a complètement ruiné mon installation, et donc obliger de formater et de réinstaller le système. (J'ai du donc attendre la version finale qui, elle ne causait pas de crash à la mise à jour)

    Depuis ce coup, j'aimerais bien tester la 35, mais je suis frileux à l'idée que ça se passe mal comme la dernière fois. Et comme c'est mon OS principale avec toute l'utilisation qui s'en suit… Je suis pas chaud.
    Je suis pourtant bien la procédure, mais ce qui serait intérressant, c'est un système robuste qui en cas de crash permette de revenir sainement en arrière.

    • [^] # Re: Frileux

      Posté par  (site Web personnel) . Évalué à 3.

      Je ne connais pas Fedora, mais n'y a t'il pas une solution à base de BTRFS et Timeshift ?
      Après, ce que tu décris est plutôt normal, une beta peut casser ton install.

      • [^] # Re: Frileux

        Posté par  . Évalué à 0.

        Je ne me suis pas posé la question, je suis en XFS :D
        Mais sinon, oui, il y a btrfs et timeshift sous fedora

    • [^] # Re: Frileux

      Posté par  (site Web personnel) . Évalué à 2.

      Je ne me suis jamais lancé dans la chasse aux bogues des nouvelles versions de Fedora Linux, je suis encore plus frileux que toi, j'attends toujours un ou deux mois avant de faire la mise à jour vers la nouvelle version. Mais je me pose cette question : est-il possible de tester dans une VM, ou faut-il absolument le faire en dur ?

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: Frileux

        Posté par  . Évalué à 2.

        bah, ça dépend de ce que tu veux faire!
        1/ Tester la bêta dans un environnement virtualisé? Voir si ça marche avec virtualbox, vmware, qemu?
        2/ Tester sur du matériel réel avec vrai GPU/CPU et drivers associés? Performances réel? Usage réel voir quotidien?

        Si tu rencontres un problème en virtuel, serait ce la même sur du vrai matériel? Et inversement?

        • [^] # Re: Frileux

          Posté par  (site Web personnel) . Évalué à 3.

          Ça fait beaucoup de questions comme réponse à la mienne ;)

          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: Frileux

        Posté par  . Évalué à 4.

        Tout dépend de savoir ce que tu testes.

        L'installer dans une vm, si après tu ne l'utilises pas vraiment au quotidien parce que tu as déjà tout en local, bof. Et ça ne teste de toute façon pas l'upgrade.

        Moi j'ai 3 laptops sous fedora donc je passe en général la beta sur le laptop perso (qui sert de toute manière plus à mes enfants qu'à moi), puis sur les 2 autres à usage plus professionnels 1-2 semaines après la sortie officielle si je ne vois pas de grand drame sur l´internet.

  • # à propos de WirePlumber

    Posté par  (site Web personnel) . Évalué à 7.

    WirePlumber va gérer les sessions Pipewire pour l'audio dorénavant plutôt que ce que Pipewire utilise en interne

    Cela peut paraître flou pour ceux qui ne connaissent pas, aussi voici une description plus détaillée, issue de l'annonce initiale du projet :

    PipeWire upstream has a very limited example session manager. It serves as a good example for building new ones and has some functionality there for basic desktop use cases and testing, but it goes no further than that. WirePlumber serves as a replacement for this example and additionally provides a framework for building custom session managers.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.