Journal L'histoire d'un bug

Posté par  .
Étiquettes :
0
25
juil.
2005
Ce week end, décidant de définitivement de remplacer la (K)ubuntu qui trainait sur mon portable et qui ne me permettait pas de lire des vidéos à cause d'un bug sur le module Xv, j'ai décidé d'installer une Fedora Core 4. J'avais déja fait une tentative, qui ne m'avait pas convaincu du tout à cause des trop nombreux bugs qui ont marqué cette release.

Cependant, je sais que Fedora corrige les bugs rencontrés par des updates conséquentes, et c'est pour ça qu'une tentative près d'un mois après sa sortie me paraissait intéressante.

Premier bug, déjà rencontré lors de la première installation : Anaconda en français ne marche pas (c'est le cas avec de nombreuses langues) avec l'image boot.iso, signe qu'ils ne se sont pas donnés la peine de la tester dans d'autres langues que l'anglais. Un bug assez curieux étant donné que Red Hat était considéré avant Fedora comme assez méticuleuse.

Ensuite, l'installation en mode graphique ne marche pas, seule l'installation en mode texte fonctionne. Le premier boot après l'installation me donne un écran vide, sans possibilité de switcher vers le mode console. En effet, et c'est le bug dont je voulais vous parler, X démarre avec un écran bleu, sans aucune trace dans les logs permettant d'investiguer quoique ce soit.

Après recherche de solutions, en retirant "rhgb" des paramètres passés au noyau par grub, je peux switcher lors du boot vers une console. Je peux ainsi éditer /etc/inittab pour qu'il ne démarre pas en mode graphique.

Je peux donc tester la correction de bugs via les mises-à-jour, imaginant que mes problèmes étaient forcément résolus. Et ba non, aucune amélioration malgré la plétore de paquets mis à jour.

Déçu par Fedora, je tente successivement Frugalware (installation des packages plantés à la moitié du process, plantage de X au démarrage), puis Arch Linux (plantage de X), et enfin PC-BSD (plantage de X).

Ce dernier m'a mis la puce à l'oreille, en proposant dès l'installation de switcher vers le module standard Vesa, et non le module Trident qui gère ma carte graphique Trident CyberBlade i1. J'ai donc pu installer cet OS que je ne connaissais pas en mode graphique (malgré quelques soucis de clavier non paramétrable lors de l'installation).

Ou veux-je en venir me direz vous ? Le bug que j'ai rencontré est un bug majeur par son ampleur comme me l'ont confirmé les différents rapports de bug. De plus, il ne concerne pas qu'une distribution, ni même un OS, les BSD étant impactés. Sont concernés :
- Matrox G550,G400,autres
- Intel i845,i852,i855,i865
- Trident Cyberblade
- S3 Inc. 86C270-294 Savage/IX-MV (rev 13), S3 ProSavage Twister 4
.....

D'où vient il ? De libvgahw (paquet Xorg), d'une compilation compliquée par gcc, de différences d'interprétation dans le standard C.

Que faire si vous avez ce bug ? Switcher sur Vesa, ou s'attaquer à des manipulations compliquées.

Mes conclusions :
- Fedora, c'est vraiment pas Red Hat. Mike harris, qui s'occupe de ce bug part en vacances trois semaines, dont pas de corrections dans les jours à venir. A quoi sert la communauté dans ce cas ? Les tests non réalisés par Red Hat sur le boot.iso, tout le monde s'en fout parce que tout le monde parle anglais ? Fedora a un errata, pourquoi ne pas mettre un petit lien vers le rapport de bug ?
- PC-BSD, c'est bien, mais s'ils pouvaient inclure la gestion des dispositions de claviers, des langues, de la zone horaire, ça serait beaucoup mieux.
- Ce problème va toucher beaucoup de newbies, comment leur expliquer la correction ?

Des petits liens pour tout expliquer :
- le rapport sur le bugzilla de Fedora (très complet) : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242(...)
- le bug sur GCC : http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278(...)

C'était ma minute "je raconte ma vie", désolé à ceux qui m'ont lu :)
  • # moment \o/*

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

    http://www.livejournal.com/users/gravityboy/16932.html(...)

    J'avais déjà lu ça car cette personne doit être dans le planet de Debian ou du Kernel, mais après test, c'est aussi dans les premiers liens de google pour: "ubuntu xorg libvgahw".

    Ça ne règle pas ton problème ?
    • [^] # Re: moment \o/*

      Posté par  . Évalué à 2.

      Le problème, à priori vient bien de là : gcc4 est incompatible avec Xorg sur certains drivers. Pour moi, le problème ne sera résolu que lorsque les ditributions sortiront des gcc patchés, ou qu'une nouvelle version de gcc sortira. Reste que pour le moment, de nombreuses distributions sortent avec des configurations ne fonctionnant pas. En fait, presque toutes les distributions mineures sorties récemment, ainsi que Fedora. Ca va en faire du monde à aider, non ? Mon cas perso : je suis sous PC-BSD (donc un FreeBSD), je vais chercher quelles sont les solutions qu'ils proposent, je verrais ensuite.
      • [^] # Re: moment \o/*

        Posté par  . Évalué à 2.

        Mon cas perso : je suis sous PC-BSD (donc un FreeBSD), je vais chercher quelles sont les solutions qu'ils proposent, je verrais ensuite.
        Il utilise des gcc-4 sous freebsd, j'avais cru lire quelque part qu'il comptait rester sous la 3.x pendant quelques temps...
        • [^] # Re: moment \o/*

          Posté par  . Évalué à 2.

          Tu as raison, je viens de vérifier, c'est gcc 3.4.2.
          Du coup, je ne comprends plus rien. En tout cas, le driver Trident est bien buggé et je suis obligé de rester sur vesa.
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: moment \o/*

          Posté par  . Évalué à 1.

          elle attendra patiemment que les geeks ou les marketeux qui bavent sur les dernières versions s-y cassent les dents.
          Je ne vois personellement aucun problème à cela. Fedora a le droit de fournir des logiciels à la pointe, ça a l'avantage de faire remonter beaucoup plus de bugs et ça participe au mouvement. Par contre, dans ce cas là, on écrit en gros sur le site : Attention, Fedora est une pre-alpha destinée aux rapporteurs de bugs et aux geeks, ne la conseillez jamais à personne. En tout cas, je ne comprends pas ceux qui considèrent Fedora utilisable comme poste de travail (en entreprise). Sur d'autres ordinateurs j'ai eu droit à des crashs de nautilus, d'Openoffice, etc...

          PS: j'ai tenté une slackware 10.1 mis à jour avec les packages de http://www.kde.org.(...) J'ai eu d'autres problèmes (packages i18n non existants, slackpkg erzatz de gestionnaire de packages). Ce qui me dérange le plus chez Slack, c'est le manque de centralisation d'infos sur slackware.com (par exemple les sources de packages conseillés par Patrick). A mon avis, Slackware est un miscrocosme dans lequel il est difficle de s'introduire : pas de mailing list, pas de bugzilla, etc...
          • [^] # Re: moment \o/*

            Posté par  (site web personnel) . Évalué à 4.

            The Fedora Project is an open source project sponsored by Red Hat and supported by the Fedora community. It is also a proving ground for new technology that may eventually make its way into Red Hat products. It is not a supported product of Red Hat, Inc.

            La sarge n'a pas de gcc4 par défaut il me semble. C'est assez casse bonbon ces gens qui se plaignent que les distribs type fedora core ou debian sid ne fonctionnent pas correctement, elles sont là pour ça. Pour la ubuntu je suis d'accord que c'est pas chouette mais y'a un bugzilla et y'a des correctifs semble t il.
        • [^] # Re: moment \o/*

          Posté par  . Évalué à 7.

          Aucun problème avec Linux Slackware. Il faut dire que c'est pas demain la veille qu'elle sera livrée avec GCC4 en standard : comme d'habitude, elle attendra patiemment que les geeks ou les marketeux qui bavent sur les dernières versions s-y cassent les dents.

          Je me demande où en serait le logiciel libre si tous le monde réagissait comme ça...
          et je me réponds... qu'il ne peut pas y avoir de rapports de bugs sur un logiciel qui n'est pas utilisé...
          Alors la politique de "on ne touche à rien, ça marche" c'est bien... mais ça fais pas beaucoup avancer le smillblick !!
  • # bein tu prends ton clavier ...

    Posté par  (site web personnel) . Évalué à 1.

    - Fedora, c'est vraiment pas Red Hat. Mike harris, qui s'occupe de ce bug part en vacances trois semaines, dont pas de corrections dans les jours à venir. A quoi sert la communauté dans ce cas ?
    la communauté n'est pas ton service petit et si tu veux une solutions qui fonctionne sans attendre 3 semaines et bien tu codes et tu fais particper ton code en le "donnant " à la communauté !
    • [^] # Re: bein tu prends ton clavier ...

      Posté par  . Évalué à 2.

      Le code et les rpms faits par la communauté sont à disposition sur des ftp de membres de la communauté, mais pas dans les dépôts officiels Fedora. Comme un employé Red Hat part en vacances, il n'y a personne pour mettre à dispo le rpm. Dans un projet communautaire digne de ce nom, lorsqu'une personne part en vacances, une autre peut le remplacer; visiblement ce n'est pas le cas pour Fedora.
      • [^] # Re: bein tu prends ton clavier ...

        Posté par  (site web personnel) . Évalué à 0.

        achete une license RHEL si tu veux du support. Je doute (j'ai pas lu, mais comme je n'utilise pas fedora c'est normal) que sur le site il soit indiqué qu'avec la distribution gratuitement disponible fedora tu aies un support premium avec un type qui vient te faire le café quand t'arrives pas à dormir.
        Le type il est parti en vacances et tant mieux pour lui. Fedora n'est absolement pas destinée a des utilisations critiques où un bug doit être corrigé dans la minute.
        • [^] # Re: bein tu prends ton clavier ...

          Posté par  . Évalué à 4.

          Ceci dit, il peut très bien faire remarquer que sur le plan organisationnel, la communuaté Fedora peut s'améliorer...
  • # Même problème, Trident Cyberblade i

    Posté par  . Évalué à 1.

    J'ai moi aussi une Trident Cyberblade i1 dans mon ordinateur portable (qui se fait un peu vieux d'ailleurs, et que je vais pas tarder à changer...)
    Et j'ai déjà eu le même problème avec ce bug du driver xv (insupportable!!). J'étais alors en ubuntu warty.
    Une mise à jour, en suivant les upgrades notes sur http://www.ubuntulinux.org/support/ReleaseNotes504/(...) , a alors résolu mon problème, j'étais heureux.

    Comme workaround, pour lire les vidéos, j'arretais le serveur X, et dans un petit tty:
    mplayer -vo vesa -fs -zoom RichardStallman2005.avi
    La qualité de la lecture avec le driver vesa n'est pas excellente (une petite granularité me fait amplement préferer xv).

    J'avais fait pas mal d'investigations: pensant que ça venait de mplayer, puis de xine, totem, etc... (du jour au lendemain ça s'est mit à ne plus marcher...), j'ai aussi cru que ça venait du driver trident pour X(j'utilisais encore Xfree, Xorg m'a sauvé), mais j'ai jamais rien trouvé sur libvgahw. Ce n'était peut etre pas le même problème, mais le bug de lecture vidéo me semble assez similaire (pas de white screen, ou de trucs bizarre, excepté au changement de résolution)


    Sinon, la bonne technique consiste à éviter de mettre à jour les paquets "critiques", sauf bug de sécu: ça évite les mauvaises surprises quand le système marche déjà. C'est déjà la politique d'ubuntu.
    • [^] # Re: Même problème, Trident Cyberblade i

      Posté par  . Évalué à 2.

      J'étais en Ubutu Hoary. Je me suis posé les mêmes questions que toi, à savoir : est ce que ça vient de mplayer, xine, totem, etc... Je n'avais pas pensé que cela pouvait venir de X directement. Maintenant que je me souviens, je crois que cela fonctionnait avec une installation fraiche. Bref, ce bug est ici : https://bugs.freedesktop.org/show_bug.cgi?id=736(...) , il n'a à priori aucun rapport avec libvgahw et l'autre bug dont je parle dans la suite de mon journal. Si j'étais développeur, et que je connaissais le fonctionnement de Xorg, je ferais bien qqchose pour le corriger. Si ça peut inciter des vocations....

Suivre le flux des commentaires

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