Fedora 31 bêta peut être testé

Posté par (page perso) . Édité par ZeroHeure, Davy Defaud et Ysabeau. Modéré par ZeroHeure. Licence CC by-sa.
Tags :
24
17
sept.
2019
Fedora

En ce mardi 17 septembre, les utilisateurs du Projet Fedora seront ravis d’apprendre la sortie de la version bêta de Fedora 31.

Malgré les risques concernant la stabilité d’une version bêta, 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 31 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 22 ou 29 octobre.

Sommaire

Expérience utilisateur

  • passage à GNOME 3.34 ;
  • la roue tourne pour Xfce avec la version 4.14 ;
  • mise à jour de DeepinDE 15.11 ;
  • Firefox utilise Wayland nativement par défaut, bien entendu si la session de bureau le permet ;
  • les applications Qt utiliseront de manière analogue Wayland lors d’une session GNOME sous Wayland ;
  • les paquets RPM utilisent le format de compression zstd au lieu de xz ; le temps de décompression est bien plus rapide d’un facteur trois ou quatre pour le paquet Firefox par exemple, mais générer un paquet est légèrement plus long.

Gestion du matériel

  • le noyau Linux i686 n’est plus généré et les dépôts associés sont également supprimés ; de fait, il n’y aura plus d’images de Fedora pour cette architecture, ni mise à niveau possible depuis Fedora 30 pour ces utilisateurs ; des paquets i686 peuvent subsister dans les dépôts à destination des utilisateurs ayant l’architecture x86-64 uniquement ;
  • le spin Xfce de Fedora dispose d’une image pour l’architecture AArch64 ;
  • sur les machines avec la fonctionnalité Secure Boot de l’UEFI activée, GRUB peut maintenant utiliser ses modules de sécurité nativement.

Internationalisation

  • les paquets langpacks sont subdivisés avec une partie langpacks-core qui ne propose que la police par défaut et la locale correspondante, l’utilisateur a donc plus de flexibilité à ce niveau ;
  • mise à jour d’IBus 1.5.21 ;
  • les polices Google Noto variables auront maintenant la priorité sur les polices non variables du même fournisseur.

Administration système

  • le binaire /usr/bin/python fait référence dorénavant à Python 3 et non Python 2 ; en effet, Python 2 ne sera plus supportée par le projet officiel en janvier 2020, le projet Fedora respecte donc la PEP 394 pour entamer la transition ; en cas de problèmes vous pouvez créer le lien symbolique ~/.local/bin/python pour un utilisateur ou /usr/local/bin/python pour le système entier afin de restaurer le comportement habituel ;
  • de fait, il y a une suppression massive de paquets Python 2 pour ne garder essentiellement que les derniers projets non convertis à Python 3 aujourd’hui ;
  • la fonction des politiques de sécurité, introduite peu à peu dans Fedora ces dernières années, offre maintenant la possibilité aux administrateurs de personnaliser les règles comme le choix des protocoles de sécurité utilisables ou non sur le système ;
  • le noyau propose les cgroups 2 au lieu de la version 1 utilisée jusqu’alors ;
  • OpenSSH refuse par défaut les identifications par mot de passe pour le compte super‐utilisateur ;
  • tous les groupes utilisateur ont la possibilité native de faire des ping sur le réseau sans binaire setuid, c’est surtout à destination des environnements avec conteneur ou Fedora Silverblue ;
  • le compteur RPM atteint la version 4.15 ;
  • si un dépôt est non accessible, DNF émettra une erreur par défaut au lieu d’un avertissement ; c’est surtout à destination des dépôts tiers qui n’activaient pas forcément cette option dans leur configuration ;
  • YUM 3 tire sa révérence, un lien symbolique vers DNF est maintenu ; son API n’est également plus accessible ;
  • les paquets liés à 389-console sont retirés au profit d’une nouvelle interface Web.

Développement

  • mise à jour de la bibliothèque C glibc vers la version 2.30 ;
  • Gawk passe à la branche 5.0 ;
  • Node.js en est à son douzième nœud ;
  • le générateur de documentation Sphinx passe à la version 2 et abandonne la prise en charge de Python 2 ;
  • les tests Python passent du paquet python3-libs au paquet python3-test ;
  • le langage Go fonce vers la version 1.13 ;
  • le langage Perl reluit à la version 5.30 ;
  • mise à jour du langage Erlang et OTP à la version 22 ;
  • alors que le compilateur Haskell GHC et Stackage LTS passent respectivement eux versions 8.6 et 13 ;
  • la pile .Net libre Mono bénéficie de la version 5.20 ;
  • l’environnement et la chaîne de compilation MinGW passent la sixième ;
  • le projet Fedora propose une configuration alternative de l’éditeur de liens, pour passer aisément de celui du projet GNU LD à celui de LLVM LDD et vice versa sans changer l’environnement de développement ;
  • l’éditeur de liens GOLD de binutils, développé par Google mais maintenu par GNU maintenant, a son propre paquet binutils-gold pour facilement s’en séparer si la maintenance s’arrête ; le projet n’étant plus développé activement.

Projet Fedora

  • l’image Cloud de Fedora bénéficiera d’une nouvelle image chaque mois ;
  • Bodhi est activé sur Rawhide, poursuivant l’objectif de rendre Rawhide plus stable et améliorer l’assurance qualité ; cela signifie que la mise à jour d’un paquet sur Rawhide doit suivre le même processus que pour une version stable ;
  • les sources RPM peuvent avoir des dépendances lors de la compilation générées dynamiquement ; en effet, de plus en plus de langages comme Rust ou Go gèrent eux‐mêmes les dépendances pour compiler un projet, ainsi, l’empaqueteur n’a plus pour ces projets à recopier les dépendances que le projet a déjà lui même renseigné ;
  • de nouvelles règles d’empaquetage pour les projets utilisant Go ont été édictées ;
  • l’environnement de compilation de Fedora, le buildroot, utilise un gdb minimal pour gagner en efficience ; il ne dispose plus de la gestion du XML ou de Python ;
  • les dépendances autour du langage R peuvent maintenant être résolues automatiquement ;
  • le paquet glibc i686 nécessaire pour le buildroot de Fedora bénéficie d’une amélioration de sa compilation pour être plus maintenable et garantir le respect de la licence LGPL.

Tester

Durant le développement d’une nouvelle Fedora, comme cette version bêta, 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 de qualité élabore et propose une série de tests, en général simples à exécuter. Il suffit de les suivre et d’indiquer si le résultat est celui attendu. Dans le cas contraire, un bogue devra être ouvert pour permettre l’élaboration d’un correctif.

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 vous avez une bêta exploitable sous la main, ça requiert souvent peu de temps (15 minutes à une heure maximum). Si l’aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

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

Bons tests à tous !

Aller plus loin

  • # Tests

    Posté par . Évalué à 1 (+1/-0).

    Et d'ailleurs en parlant de tests, demain (mercredi) semble être la journée consacrée au test de GNOME 3.34 !

  • # erreur de version?

    Posté par . Évalué à 3 (+1/-0). Dernière modification le 18/09/19 à 06:15.

    Sphinx vient de passer en version 3. Cela fait des années que Sphinx existe en version 2, je pense qu'il s'agit d'une coquille.

    https://www.sphinx-doc.org/en/master/

  • # Réactivité sur le bug tracker

    Posté par . Évalué à 5 (+5/-0).

    Je suis mitige quant a cette dépêche.

    J'utilise Fedora depuis plusieurs années (car a l’époque c’était la seule distro qui supportait bien la techno Optimus) mais quasiment tous les bug reports que j'ai fait sur le tracker Fedora sont restes sans réponses pour être fermes automatiquement par le bot de fin de vie….

    • [^] # Re: Réactivité sur le bug tracker

      Posté par (page perso) . Évalué à 5 (+2/-0).

      Il n'y a pas de règles absolues à ce sujet, cela dépend des mainteneurs. Certains sont très réactifs et avenants, d'autres pas. Suivant la criticité du bogue, des informations collectées ou du moment où c'est rapporté cela peut rester lettre morte.

      C'est pourquoi il est aussi recommandé de relancer après quelques jours ou semaines sans réponses. Pour s'assurer que le mainteneur pense à lire le rapport.

    • [^] # Re: Réactivité sur le bug tracker

      Posté par (page perso) . Évalué à 5 (+3/-0).

      J'ai aussi une expérience très similaire avec la plupart de mes bugs Fedora (des bugs soit que j'ouvrais, soit que je suivais car j'avais le même). Au début même, je réouvrais les rapports après que le bot les ferme (ce que le bot demande explicitement de faire), mais depuis quelques temps, je ne prends même plus la peine. :-/

      Ceci dit, j'avais une expérience proche avec Mageia déjà (la seule différence étant qu'ils n'avaient pas de bot qui fermait les rapports automatiquement, de mémoire; ce qui est déjà bien mieux, ceci dit, car le coup du bot qui ferme un rapport que quelqu'un a pris du temps à rédiger, avec traces et logs, est extrêmement désagréable).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Réactivité sur le bug tracker

      Posté par (page perso) . Évalué à 9 (+7/-0).

      "quasiment tous les bug reports que j'ai fait sur le tracker Fedora sont restes sans réponses pour être fermes automatiquement par le bot de fin de vie…"

      Sur quels paquets avais-tu rapporté des bugs ?

      Utilisateur de Fedora de longue date, j'ai aussi vu plusieurs de mes bugs rapportés à Fedora rester lettres mortes.

      Déjà, il faut comprendre que Fedora est une distribution Linux, et non pas l' "upstream" du projet. Le ou les responsables d'un paquet ont parfois des connaissances limitées du projet qu'ils empaquetent. Il n'est pas rare qu'une seul personne soit responsable d'une dizaine de paquet, sinon plus.

      Parfois, le bug est rare et difficile à reproduire. Je maintiens Python pour Fedora, et récemment on a reçu un bug que le rapporteur reproduisait sans problème, alors qu'en s'y mettant à 4, aucun n'a réussi à reproduire le bug. Même en demandant des informations complémentaires à plusieurs reprises, on n'a pas réussi. Il faut comprendre que Fedora est un système complet : un bug dépend rarement d'un seul composant, c'est souvent la combinaison des plusieurs composants dans des versions précises combinées à une configuration utilisateur particulière. Reproduire la configuration de l'utilisateur produisant le bug n'est pas trivial. Exemple anodin : certains bugs dépendent de la locale (langue) de l'utilisateur.

      Mais plusieurs fois, le bug que j'ai rapporté a été corrigé entre 1 semaine et 1 mois.

      Fedora a un outil génial pour collecter des traces lors d'un crash ABRT. L'outil reconstruit la pile d'appel via un serveur dédié sans que l'utilisateur ait besoin d'avoir l'outillage (notamment les symboles de debug) installés en local. C'est efficace, mais encore une fois, "voir" un crash ne suffit pas à reproduire les conditions qui permettent de reproduire le bug.

      Certains packageurs sont employés par Red Hat. Certains sont volontaires. Certains travaillent uniquement sur Fedora. Certains travaillent sur Fedora et RHEL. Il y a beaucoup de cas.

      • [^] # Re: Réactivité sur le bug tracker

        Posté par (page perso) . Évalué à 1 (+0/-0). Dernière modification le 25/09/19 à 07:37.

        Je ne peux que confirmer vos commentaires malheureusement.

        Je suis volontaire pour rapporter des bugs, mais si ils ne sont pas traités derrière, je ne veux plus m'impliquer dans ce process de qualité.

        Et je ne me suis remis de juillet dernier, ou ils ont poussé une maj qui a fait explosé le driver Wifi.

        Bug report évidemment: https://bugzilla.redhat.com/show_bug.cgi?id=1732165

        et 2 semaines après, toujours aucun paquet pour corriger ce problème…

        J'ai du trouver un câble ethernet dans l'urgence pour pouvoir faire un downgrade du paquet le soir-même.

      • [^] # Re: Réactivité sur le bug tracker

        Posté par . Évalué à 3 (+1/-0).

        "quasiment tous les bug reports que j'ai fait sur le tracker Fedora sont restes sans réponses pour être fermes automatiquement par le bot de fin de vie…"

        Le « bot de fin de vie » !

        La meilleure métaphore qui soit depuis la Grande Faucheuse… :-)

    • [^] # Re: Réactivité sur le bug tracker

      Posté par (page perso) . Évalué à 5 (+3/-0).

      Tiens je suis surpris du constat général. Je n'ai fait que 2 rapports de bugs, mais les deux ont été traités assez rapidement.

      Celui dont je me souviens le mieux c'était un lecteur de carte mémoire d'un ordi. portable Dell non détecté. De mémoire, c'était remonté upstream au niveau kernel, en tout cas ça avait été solutionné en moins d'un mois.

      Ceci-dit c'est assez vieux, ça a peut-être changé. Depuis j'utilise une autre distribution (Fedora est très bien mais je voulais une rolling release)

  • # Firefox + Wayland : enfin !

    Posté par (page perso) . Évalué à 9 (+7/-0).

    Firefox fait parti des dernières applications de mon desktop GNOME utilisant encore l'API X11 et nécessite le serveur Xwayland (émulation X11 pour Wayland). Parfois au lancement, la fenêtre Firefox était à moitié noire (genre à moitié dessinée), alors le motto Wayland est “Every frame is perfect” (chaque image est parfaite).

    J'étais un des premiers à tester Wayland sous Fedora, en choisissant volontairement "GNOME (Wayland)" au login. Au début, plusieurs features me manquaient avec Wayland : raccoucis clavier (ALT+e pour lancer un terminal, m'enfin !) et capture d'écran. gnome-screenshot et GIMP peuvent à nouveau faire des captures d'écran. Le partage d'écran fonctionne dans Bluejeans. Et je peux à nouveau définir des raccourcis clavier via gnome-shell (à configurer dans les paramètres globaux de GNOME).

    Dans Fedora 30, j'ai forcé l'usage de Wayland pour Firefox en mettant MOZ_ENABLE_WAYLAND=1 dans /etc/environment. Il est aussi possible de lancer "firefox-wayland", mais je préfère taper ALT+F2 puis "firefox" (plus court !) :-)

    Bref, ça marchait bien jusqu'à une régression il y a une semaine :-( Entre deux versions mineures de Firefox 69, le rendu Wayland s'est mis à produire plein de glitches assez pénible à l'usage :
    https://bugzilla.mozilla.org/show_bug.cgi?id=1580152

    Je suis plutôt content car mon collègue Martin Stránský a rapidement eu vent du bug et travaille d'arrache pied sur un correctif. Ce matin j'ai lu "Martin, I installed the firefox-69.0-7.fc31 build you did today and it does seem to fix this, on my local system at least. Not sure if it fixes the openQA issue yet (it'll be easier to tell when it's submitted as an update). Thanks!". À priori, le bug vient d'être corrigé dans Fedora 31 (mais pas encore dans Fedora 30).

    Au passage, j'ai galéré à comprendre d'où venait le bug. Mon laptop a 2 GPUs ce qui rend le debug plus complexe. J'ai écrit un article pour expliquer cette technologie du futur un peu bizzare qui vise à augmenter l'autonomie des laptops, "Hybrid Graphics" :

    "Hybrid Graphics issues on Linux"
    https://vstinner.github.io/debug-hybrid-graphics-issues-linux.html

    --

    Par le passé, j'avais déjà eu un bug majeur avec Firefox + Wayland, que j'ai du corrigé moi même en backportant un correctif Gtk. Sélectionner plus de 4000 caractères plantait tout Firefox :-( CTRL+a dans Gmail plantait Firefox, super pénible.

    https://bugzilla.mozilla.org/show_bug.cgi?id=1539773
    https://gitlab.gnome.org/GNOME/gtk/issues/1783
    https://src.fedoraproject.org/rpms/gtk3/pull-request/5

    La bonne nouvelle est qu'avec le libre, on peut corriger les bugs soit même si on sait faire ;-)

    • [^] # Re: Firefox + Wayland : enfin !

      Posté par . Évalué à -3 (+2/-0).

      Bug Firefox ou bug Fedora-firefox?
      Si c'est le premier : est-ce remonté à mozilla.si c'est le second, qu'est-ce qu'à modifié Fedora?

      • [^] # Re: Firefox + Wayland : enfin !

        Posté par (page perso) . Évalué à 5 (+3/-0).

        Aucun bug n'est spécifique à Fedora. Le premier était un bug Firefox (remonté à Firefox), le second un bug Gtk (remonté à Gtk, mais il était déjà corrigé, alors j'ai backporté le corrrectif dans Fedora).

    • [^] # Re: Firefox + Wayland : enfin !

      Posté par . Évalué à 3 (+2/-0). Dernière modification le 18/09/19 à 20:09.

      Aaaahh ! Merci ! Je connais exactement ces bugs, mais j'ai eu du mal à trouver si un ticket a été sorti dessus ! Du coup j'avais abandonné mes recherches.
      Effectivement, il y a un espèce de flickering, qui ressemble beaucoup à ceux qu'on a pu voir sur les débuts de Wayland sous Fedora et Firefox (qui devait donc tourner pour le coup sous XWayland).

  • # snapshot

    Posté par . Évalué à -3 (+2/-0).

    Hello Renault,

    Il n'y avait pas un système de snapshot avec Fedora? Un truc avec OSTree qui permet de rollback ?

    • [^] # Re: snapshot

      Posté par (page perso) . Évalué à 8 (+5/-0).

      OStree est utilisé dans l'édition Fedora Silverblue par exemple. Il n'est pas proposé par défaut dans les éditions normales de Fedora. Je suis en train de rédiger un article complet dessus, j'espère le sortir d'ici la fin de l'année.

      Il y a la possibilité de configurer et d'activer le plugin snapper de DNF pour qu'à chaque transaction un cliché du système soit réalisé pour revenir en arrière mais je ne l'ai personnellement jamais testé. Et je crois que tous les systèmes de fichiers ne sont pas pris en charge par cette méthode.

  • # Fedora 31 bêta peut être testé

    Posté par . Évalué à 2 (+3/-1).

    Bonjour Renault.

    Merci pour l'article, j'ai testé cette Fedora 31 beta Gnome 3.34 dans Virtualbox dans le but de faire une vidéo (Youtube).
    Installation : Mon cpu a beaucoup chauffé durant l'installation ~90-99°C (une dizaine de minute).
    Reboot : création compte utilisateur (pas de compte root)
    Premier lancement : RAS
    Mise à jour : avec "Logiciels" la barre d'avancement ne se voyait pas pour ~ 40 mises à jour => Annuler pour passer par le terminal.
    Mise à jour : avec le terminal, dnf check-update puis un sudo dnf upgrade (ajout sudo car demande droit root) et là ~ 400 mises à jour. ( je comprends mieux pourquoi la barre d'avancement de "Logiciels" prenait du temps.
    Problèmes : me reste à voir pourquoi j'arrivais pas à télécharger les métadatas sur les dépôts tiers rpm-fusion.
    Installation de neofetch non possible avec "Logiciels" mais réussi dans le terminal.
    Sinon RAS pour le reste de la vidéo, c'est une bonne base de travail à peaufiner pour le 22-29 Octobre 2019.

  • # Fin du 32 bits?

    Posté par (page perso) . Évalué à 5 (+3/-0).

    S'il n'y a plus d'images du noyau générées, est-ce encore une distribution 32 bits?

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Fin du 32 bits?

      Posté par . Évalué à 2 (+1/-0).

      Vu que ça ne marche plus sur du hardware 32 bits, ce n'est plus une distrib 32 bits. Les applis 32 bits marchent toujours.

  • # retour rapide

    Posté par . Évalué à 1 (+0/-0).

    J'ai installé aujourd'hui.
    Anaconda ne m'a pas rassuré, j'ai dû faire plusieurs essais (il se plaignait des partitions qui devraient être GPT alors qu'elles le sont déjà et je ne sais quoi d'autre avec UEFI). Finalement, et je ne sais comment, mais cela a marché après plusieurs tentatives. J'ai un système avec 6 disques, mais ce n'est pas une excuse, cette partie de l'installeur doit être bétonnée. Avant d'arriver sur la page principal de l'installeur, on passe sur un écran où on choisi la langue, puis un écran pour le réseau. Pour ce deuxième écran le clavier n'est pas configuré. Je ne comprenais pas pourquoi je n'arrivais pas à me connecter à mon wifi, le mot de passe n'était pas le bon (NB: pas d'option d'affichage du mot de passe pour savoir ce qu'on tape et pas d'autre champ pour faire un essai). Vu qu'on peut configurer le réseau plus loin, avec le clavier configuré (et aussi voir le mot de passe), ce n'est pas très gênant.

    Tout le reste va presque pour le mieux dans le meilleur des mondes sauf peut-être un réglage de la vm ou cache disque qui rend le système quasi inutilisable lorsque je fais des grosses copies de fichiers et que le cache est "sous pression" (je débite entre 200 et 300 Mo/s sur mon maintenant vieux i7). C'est beaucoup mieux lorsqu'on vire le swap (j'ai assez de mémoire pour le faire). Petit désagrément pour les consoles textes, elles ne prennent pas tout l'écran. Toujours le même problème de l'interface Firefox en anglais.

    Tout le reste a bien marché "out of the box". Le DAC reconnu et utilisé par défaut, casque Bluetooth nickel, pas de soucis avec rpmfusion, etc.

    Ce n'est plus la même excitation qu'il y a quelques années. Le système évolue peu, il se peaufine. Je ne m'en plains pas.

Envoyer un commentaire

Suivre le flux des commentaires

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