Journal Ubuntu : La MAJ de xserver-xorg fait planter le serveur X

Posté par  .
Étiquettes :
0
22
août
2006
Vu que ce bug va toucher pas mal de monde il m'a semblé utile d'en faire un journal.

Le paquet xerver-xorg est proposé en tant que MAJ de sécurité sous Ubuntu depuis ce matin. Ne l'installez pas, cette MAJ rend le serveur X instable (inutilisable en gros).

Le plantage concerne la plupart des utilisateurs qui utilisent une carte ATI ou Nvidia (les intel sont épargnées).

Si vous avez quand même effectuer la MAJ, il faut revenir en arrière en installant l'ancien paquet :
sudo apt-get install xserver-xorg-core=1:1.0.2-0ubuntu10

Le rapport sur le launchpad :
https://launchpad.net/distros/ubuntu/+source/xorg-server/+bu(...)

  • # Question avant de troller ...

    Posté par  . Évalué à 5.

    C'est quelle version d'ubuntu ? Stable, unstable ?

  • # Qui test les MAJ ?

    Posté par  . Évalué à 6.

    La question mérite d'etre posée je pense. Comment vont faire les miliers de personnes qui ont ubuntu et qui ne connaissent pas la command line ? C'est vraiment pas serieux ...

    • [^] # Re: Qui test les MAJ ?

      Posté par  . Évalué à 8.

      Ils apprenent, et vite.

      • [^] # Re: Qui test les MAJ ?

        Posté par  . Évalué à 10.

        Attends, c'est quand même pas compliqué :
        - de toute façon vu que X a crashé, tu es sur la ligne de commande
        - tu lances sudo apt-get install links2 pour installer un navigateur adapté à la situation
        - links2 "forum d'Ubuntu" et recherche de quelqu'un ayant la même expérience
        - sudo apt-get install xserver-xorg-core=1:1.0.2-0ubuntu10
        - un sudo /etc/init.d/dm restart

        Franchement, pour un débutant sous GNU/Linux, c'est super intuitif, je sense que ça va bien se passer... Bon courage à eux par avance, je compatis.

        • [^] # Re: Qui test les MAJ ?

          Posté par  . Évalué à 5.

          Mais... et son dual boot windows pour les jeux, il sert à quoi ?

          • [^] # Re: Qui test les MAJ ?

            Posté par  . Évalué à 3.

            il y a aussi le live cd qui leur a servit pour faire l'installation...

            • [^] # Re: Qui test les MAJ ?

              Posté par  . Évalué à 2.

              Ah oui tiens, je vais dire à mon père: "Faut re-installer, pôpa, bon courage!"

              • [^] # Re: Qui test les MAJ ?

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

                Je pense qu'on a voulu te dire que l'on peut se servir du livecd pour visiter un quelquoncque forum ou channel qui etaient tous au courant dans l'heure qui suit la mise a jour et qui pouvaient donner une solution de depannage.

                Si tu te dis "oui mais pourquoi il penserait a aller voir ce genre d'endroits", sache qu'une specification d'edgy est d'implementer un programme qui enverrait l'utilisateur directement sur le channel de sa langue choisie, depuis le menu d'aide.

                • [^] # Re: Qui test les MAJ ?

                  Posté par  . Évalué à 3.

                  J'avais bien compris, mais faudrait déjà que mon pôpa, en mon absence (j'habite loin, trés loin) se dise "tiens, et si j'utilisais le live-cd!"
                  Il comprend déjà pas ce qu'est un "live cd" et n'aurait à priori pas à le savoir.
                  A supposer qu'il en ait l'idée,
                  et que son BIOS fasse booter sa machine sur le CD (en l'occurence, oui, mais supposons)
                  et qu'il arrive à configurer son modem ADSL USB (galère ces bêtes là)
                  et qu'il arrive à configurer sa connexion ADSL
                  et que la solution évite de parler de "ligne de commande"
                  et...

                  ca en fait des "si", alors qu'à la base, il a un système "clickodrome" installé et configuré pour lui, en qui il avait confiance ("aaah, c'est comme Windows, c'est facile Linux en fait...", bah oui, pôpa a été elevé avec ça) et il n'avait rien à faire à part les mises à jour, pour la sécurité.

                  Le plus "simple", c'est encore une re-installation (et encore, ca necessite de maitriser le BIOS, et savoir installer le modem etc... mais au moins, on saute l'étape "lignes de commandes")

                  • [^] # Re: Qui test les MAJ ?

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

                    Alors des idées pour ces problèmes la :

                    « faudrait déjà que mon pôpa se dise"tiens, et si j'utilisais le live-cd!" »
                    L'installation passe par le livecd. Il suffit de rajouter à un moment donné que si ca foire on peut rebooter sur le livecd pour remettre la configuration à 0 par exemple.

                    Donc il en aura l'idée.

                    « et que son BIOS fasse booter sa machine sur le CD (en l'occurence, oui, mais supposons) »
                    Pareil, si il arrive à installer depuis le livecd (reste a avoir 100% de machines installables par le live cd)

                    « et qu'il arrive à configurer son modem ADSL USB (galère ces bêtes là) »
                    « et qu'il arrive à configurer sa connexion ADSL »
                    Si il a pu mettre à jour, c'est bien qu'il a une connexion à Internet non ?
                    A moins qu'il utilise un cd de mise a jour (comme le cd de la ubuntu 6.06.1 ) mais ces cds sont plus longement testés.

                    « et que la solution évite de parler de "ligne de commande" »
                    Pour ce problème la il suffisait de remettre le paquet dans son ancienne version en attendant celle d'après. C'est faisable automatiquement donc pas trop de problèmes.

                    Après, oui il peut toujours y avoir des problèmes du genre, mais je pense que grâce à la communauté on peut les resoudre facilement a posteriori.

                    • [^] # Re: Qui test les MAJ ?

                      Posté par  . Évalué à 2.

                      Si il a pu mettre à jour, c'est bien qu'il a une connexion à Internet non ?

                      Pour ma part, connecté en Wifi avec chiffrement WEP (oui je sais, le WEP c'est pas securisé), ce matin, en démarrant l'ordi j'étais ravi...
                      Pas de X, donc pas de NetworkManager, donc pas de réseau, donc pas de mise à jour...

                      J'ai reconfiguré mon serveur X en nv, puis en vesa, mais ça n'a pas pas marché... J'ai essayé de jouer avec iwconfig pour mettre ma passphrase WEP mais je n'ai pas trouvé malgré la lecture du man. (iwconfig ath0 key s:xxx ne paramétrait pas la clef dans le bon mode de chiffrement). J'ai chercher une interface texte à NetworkManager mais nm-tool n'a pas l'air de permettre de modifier les paramètres/se connecter...

                      Résultat, il a fallu que je sorte un cable réseau! Heureusement qu'il y en avait un qui traînait dans le placard!

                      En 2 ans de debian unstable, j'avais jamais eu un tel problème, parce que en sid, avant de faire une mise à jour, tu regardes un peu. Sur ubuntu, si je vois une mise à jour, poum, j'upgrade sans me poser de question...

                      Le paquet n'a donc pas été suffisament testé et sérieusement, à partir du moment où ce bug BLOQUANT était connu, il fallait proposer automatiquement une "mise à jour" vers l'ancienne version.

    • [^] # Re: Qui test les MAJ ?

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

      à quand le mode sans échec sous linux ;) ?

      • [^] # Re: Qui test les MAJ ?

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

        Il y a deja un tel mode pour ubuntu proposé par defaut, dans le menu de grub, on peut lancer son ubuntu sans aller au runlevel 2, ca donne un acces root en ligne de commande.

        • [^] # Re: Qui test les MAJ ?

          Posté par  . Évalué à 3.

          Heu ouais mais le mode sans echec sous windows y'a une GUI et des outils genre msconfig, mmc, regedit etc pour reconfigurer ce qui ne va pas sans trop de problème.

          Un acces root à la ligne de commande, ce n'est pas vraiment ce que cherchent les utilisateurs d'Ubuntu.

          • [^] # Re: Qui test les MAJ ?

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

            Ils sont deja sur la voie avec

            https://launchpad.net/distros/ubuntu/+spec/xserver-failover

            Il manque plus qu'un script avec une gui qui s'occuperait de diagnostiquer le problème et le corriger si possible.

          • [^] # Re: Qui test les MAJ ?

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

            Sous Mandriva, en mode "rescue", c'est aussi la ligne de commande... par contre il y a accès aux outils drak* qui sont le pendant curses des outils graphique. Ca dépanne bien (bon, on peut toujours aller bidouiller les fichiers de config à la main - juste que ça lasse).

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: Qui test les MAJ ?

            Posté par  (Mastodon) . Évalué à 1.

            msconfig, mmc, regedit

            C'est sur qu'avec ça la nièce de madame Michu va vite arriver à remettre sa machine d'aplomb... Un accès root au clitodrome pervers, c'est pas vraiment ce que veulent les yusers de Windows...

  • # Pas si étonnant

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

    À mon avis, ce genre de nouvelle est le dual logique de

    http://www.linuxfr.org/~niconux/22335.html
    (ubuntu la plus réactive pour les maj)

    Quand on touche quelque chose sur un système supposé stable, soit on teste à mort, soi on prend le risque que ça casse quelque chose (... soit on est dieu, mais c'est rare).

    Alors c'est vrai qu'on se fout bien de la gueule des distribs ou OS qui mettent du temps à sortir leurs maj, mais faut trouver le compromis et c'est pas facile !

  • # le Fix.

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

    Fix @ http://www.ubuntuforums.org/showthread.php?t=241254

  • # Gonflé

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

    Y a pas à tortiller du cul ... ils sont fort chez Canonical pour vendre du support avec la LTS !

    Respect !

    ^_^

  • # Drivers proprios

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

    Il semblerai que ce problème n'affecte que les cartes ATI ou NVidia avec driver proprio.

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

  • # Ouf...

    Posté par  . Évalué à 5.

    Avec le retard qu'a Ubuntu sur les versions 64bits, je suis sauvé ^^

  • # Vitesse de réaction

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

    Ce qui est intéressant, c'est la vitesse de réaction, pas le bug. Un bug, ça peut arriver n'importe quand et surtout quand on s'y attend pas.
    https://launchpad.net/distros/ubuntu/+source/xorg-server/+bu(...)

    Bug rapporté le "2006-08-21 21:37:15 UTC"

    * 1ere réaction de Rodrigo à "2006-08-22 07:39:26 UTC" (I'm working on an update to xorg-server as we speak.)

    * 2e réaction de Rodrigo à "2006-08-22 09:08:58 UTC" (Unfortunately I am not able to reproduce this locally)

    * À "2006-08-22 09:24:04 UTC", João Pinto teste les patchs indépendement et détecte le patch mis en cause (patch "005") (trouve l'origine exacte du bug)

    * Rodrigo poste alors une nouvelle version à "2006-08-22 09:36:42 UTC".

    * À "2006-08-22 09:37:21 UTC" le bogue est fermé étant donné qu'une nouvelle version est dispo sur le serveur central (et bientôt dans le "monde entier" le temps que les miroirs répliquent le paquet)

    21h => 9h, ça fait euh ... 12h pour corriger le bug. C'est raisonnable non ? Et puis, ce bug semblait assez particulier car il ne touchait pas tout le monde (c'est une histoire de truc PCI).

    Haypo, qui a attendu 20h (heure Française) pour faire la mise à jour vers le paquet 1.0.2-0ubuntu10-4

    • [^] # Re: Vitesse de réaction

      Posté par  . Évalué à 4.

      Ca, c'est la très bonne news, félicitations à l'équipe d'Ubuntu pour sa réactivité.
      La mauvaise news, c'est que le package d'update qui a causé le problème n'a pas été suffisament testé et n'aurait jamais dû être proposé en update. De là, il faut savoir se remettre en cause pour que ça n'arrive plus jamais.
      Ce n'est pas la première distribution à avoir un bug grave lié à des matériels que le développeur spécifique ne pouvait pas voir parce qu'il ne disposait pas le matériel associé. Par exemple le bug sur les lecteurs de CD LG qui a affecté SUSE, Gentoo et celle qui s'est tout pris dans la tronche, Mandriva (Mandrake à l'époque).
      Quelle sont les pistes possibles pour éviter des désastres pareils à votre avis ?

      • [^] # Re: Vitesse de réaction

        Posté par  . Évalué à 3.

        "Quelle sont les pistes possibles pour éviter des désastres pareils à votre avis ?"

        Demander à Red Hat de devenir le Apple du monde linux et de lancer toute une gamme de hardware grand public et pro ?

        A part Microsoft, personne ne peut se payer la quantité de tests requis pour faire le moins de conneries possible sur le grand éventail de matériel PC. Et encore, même avec ça, il leur arrive d'avoir des problèmes à patcher. C'est pour ça que tous les chantres du OSX sur PC générique sont de doux rêveurs.

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 3.

          Je devrais tourner mon clavier 7 fois avant de cliquer envoyer. Donc je rajoute un truc que j'ai ommis : même à Apple, avec leur très restreinte gamme hardware, ont *déjà* (c'est rare mais c'est arrivé) eu de gros problème de compatibilité. Une certaine version d'OSX était totalement instable sur les PowerMac G5 1,8 ghz et ça a mis de très longs mois pour se corriger.

          Bref, c'est un peu facile de sauter sur Ubuntu, c'est un truc qui arrive à tout le monde.

          • [^] # Re: Vitesse de réaction

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Y'a aussi une version d'OSX qui crashait complètement sur une vaste gamme de machines dès tentative d'utilisation d'OpenGL, ce qui est assez fréquent sous OSX (rien que pour afficher une photo ou un screensaver).

            Cela n'a jamais été corrigé et les propriétaires d'une telle machine ont été invité à utiliser la version précédent d'OSX, avec tout ce que cela implique.


            Ici, pour Ubuntu, le bug est grave. Néanmoins, si il a été corrigé en 12h, on peut dire que le nombre de personnes atteintes sera assez restreint et on peut espérer que Ubuntu en tirera l'expérience pour éviter des catastrophes ultérieures bien pires.

            Mes livres CC By-SA : https://ploum.net/livres.html

            • [^] # Re: Vitesse de réaction

              Posté par  . Évalué à 3.

              Comme il a été mentionné, je pense que linux a besoin de juste quelques outils "poweruser" en plus et un petit mode sans échec efficace, sous X. Windows est livré avec une panoplie d'outils malheureusement méconnue qui facilite grandement le dépannage du système et ne demandent pas beaucoup de temps pour en connaitre le fond.

              Sinon le bug OSX, je crois qu'on parle de la même chose. Ca touchait les powermac G5 1,8ghz et il y a eu un correctif 7 mois après.
              http://www.osxfacile.com/bug.html

              7 mois ! quelle patience. En tout cas, ça appuie ce que je dis. Déjà qu'une grande entreprise qui a un cercle de matériel plutôt restreint arrive à avoir de lourds problèmes avec, je trouve ça plutôt formidable comment s'en sortent les distributions linux aujourd'hui. Et là, je les vise toutes. Y'a du boulot fabuleux mis en oeuvre pour faire avancer les choses.

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 2.

          > A part Microsoft, personne ne peut se payer la quantité de tests requis pour faire le moins de conneries possible sur le grand éventail de matériel PC
          Mais, même avec les moyens, il ne le font pas :-p Ils ont des clients pour ça !!

    • [^] # Re: Vitesse de réaction

      Posté par  . Évalué à 8.

      C'est hyper rigolo, mais dans le monde reel c'est une connerie ce qu'il a fait le gars.

      Ils ont merde avec le package precedent parce qu'il n'a pas ete teste correctement du tout. Et la, il l'a teste correctement son patch ? Vu le temps entre la correction et la release(12 minutes) on dirait vraiment pas, il n'a clairement pas eu le temps de tester la chose du tout.

      Vive le processus QA chez Ubuntu !!! Allez vite c'est une chose, faire les choses correctement c'en est une autre, et visiblement chez Ubuntu ils preferent aller vite au detriment de la qualite. Un jour faudra expliquer a ces gars la ce que c'est que les effets de bord, les regressions et tout ce genre de chose.

      • [^] # Re: Vitesse de réaction

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

        Yep, c'est vrai qu'il ne devrait proposer les updates qu'une fois par moi comme Microsoft.
        Ce systéme a fait ses preuves.

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 3.

          La difference entre eux et nous c'est que la derniere fois qu'un truc aussi serieux(la GUI qui demarre plus c'est pas la meme chose qu'une fonctionnalite un peu obscure qui ne fonctionne plus hein) est arrive avec un de nos patchs c'etait il y a longtemps, tres longtemps.
          Comme quoi on met peut-etre plus de 12h pour sortir un patch, mais on met pas des milliers de gens dans la m... a cause de patchs non testes.

          • [^] # Re: Vitesse de réaction

            Posté par  . Évalué à 2.

            [...]c'etait il y a longtemps, tres longtemps.

            Ben nous aussi, Ubuntutistes, dans 15 ans quand une telle erreur arrivera de nouveau, on pourra dire "c'était il y'a longtemps..." mais comme on est modeste, on rajoutera: "... mais c'est arrivé!"

          • [^] # Re: Vitesse de réaction

            Posté par  . Évalué à 2.

            La difference entre eux et nous c'est que la derniere fois qu'un truc aussi serieux(la GUI qui demarre plus c'est pas la meme chose qu'une fonctionnalite un peu obscure qui ne fonctionne plus hein) est arrive avec un de nos patchs c'etait il y a longtemps, tres longtemps.


            Par contre, la mise à jour mensuelle Windows 2003 Server mensuelle qui pète le réseau (DNS en vrac), et qui est suivie dans la foulée d'une mise à jour corrective le lendemain, ça c'était il n'y a vraiment pas longtemps !

            Comme quoi on met peut-etre plus de 12h pour sortir un patch, mais on met pas des milliers de gens dans la m... a cause de patchs non testes.


            Effectivement, 24 heures pour sortir un patch, qui est venu péter la solution temporaire mise en place pour pallier à la déficience de la mise à jour : double intervention !

            Merci Microsoft _o/ :-)

            • [^] # Re: Vitesse de réaction

              Posté par  . Évalué à 2.

              Ah bon ? Un patch pour le DNS qui a mis tout le monde en rade ? J'aimerais bien un lien sur ca... Un patch qui a cause des problemes a un nombre limite de gens dans des situations particulieres j'imagines bien, un patch qui met n'importe quel serveur en rade apres installation ca par contre j'attends de voir...

      • [^] # Re: Vitesse de réaction

        Posté par  . Évalué à 4.

        Si, le patch a été testé.

        la différence entre la version .2 et .3 était 2 patchs. Le dev a fait 2 versions .2-patch1 et .2-patch2 et a demandé aux gens qui avait le problème de tester ces 2 paquets.

        Seul le patch1 posait problème, donc, le dev a créé une version .4 qui est la .2-patch2.

        Et voilà, grace à la coopération des devs et des powersusers, le problème était réglé. Ils vont pouvoir s'occuper du patch1 défectueux plus sérieusement maintenant.

        Il n'y a rien qui me choque là dessus.

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 3.

          Moi non plus...

          Mais une suppression du fichier des ftp dès le problème connu m'aurait évité d'avoir à 1) réparer 2) expliquer le pourquoi du comment aux personnes à qui j'ai conseillé Ubuntu. Bon c'est leur premier problème et ils ont su tapoter les commandes requises mais j'étais bien content qu'ils aient encore windows pour les leur donner par IM...

          12 h pour corriger un problème c'est court.
          12 h à laisser se propager un problème c'est long. Surtout avec les apt-get update automatiques, tu peux considérer que 50 % des gens qui ont réglé la mise à jour à une fois par jour ont eu le problème, espérons que ce ne soit pas le réglage par défaut.

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 4.

          Et c'est ca que tu appelles tester un patch ?!

          Mais il a rien fait le gars quand il fait ca, il a verifie que le fix la tout de suite fonctionne a vue d'oeil, mais quid du reste du code ? Comment il sait que ce gros probleme(impossibilite de demarrer) ne cachait pas aussi plein d'autres problemes par exemple ? (introduits par le nouveau fix, latent depuis qqe semaines, ...) Comment il sait que corriger ce probleme ne va pas en creer d'autres ailleurs ? ... Regarder le code 30 minutes et croire ce que disent 50 beta-testers qui ne connaissent absolument rien aux techniques de tests c'est _tres tres largement insuffisant_

          Quand tu sors un patch a des millions de gens tu fais un minimum de tests de regression pour etre sur qu'il n'y a rien(t'es jamais sur qu'il n'y a rien de casse, alors disons pas grand-chose :+) ) de casse, tu fais des stress tests sur les composants senses etre utilises constamment, tu fais des tests de compatibilites pour etre sur que ca fonctionne encore avec le reste, .... La le gars il a fait comme l'etudiant moyen qui a son petit projet et qui recoit un rapport de bug, c'est pas comme ca qu'on gere une codebase qui est utilisee par des centaines de milliers de gens, tu peux pas te baser sur le feedback de 30 pekins ne connaissant rien aux techniques de test informatique et ne pas lancer une batterie de tests pour sortir un patch qui touche autant de gens.

          • [^] # STOP !

            Posté par  . Évalué à 0.

            Oui, on a compris, microsoft est la fine fleur du développement et ubuntu c'est des branques. Maintenant, va jouer ailleurs.
            Le monde du logiciel libre travaille avec des moyens limités, et l'erreur est humaine. Canonical n'est pas une grande multinationale qui peut se payer un contrôle qualité au top du top. Peut-être même que Rodrigo Parra Novo (l'auteur du cafouillage selon les changelogs) n'est pas employé par Canonical mais un bénévole (la flemme de chercher la liste du personnel :p), il mérite une grosse fessée mais pas que tu dénigres autant son travail.

            • [^] # Re: STOP !

              Posté par  . Évalué à 2.

              A partir du moment où Ubuntu s'est positionné en confrontation directe avec Windows, il n'est plus question de dire : "ils n'ont pas les mêmes moyens, ce n'est pas leur faute". Soit on propose un produit de qualité équivalente, soit on n'est pas en compétition directe.
              En l'occurence, ils ont un autre moyen qui est prodigieux : sa communauté, tout à fait capable de prendre à sa charge le fait de tester un package de mise-à-jour pour déceler des problèmes importants (comme celui-ci).
              Je rejoins à 100% PBPG sur ce coup là.

            • [^] # Re: STOP !

              Posté par  . Évalué à 1.

              Peut-être même que Rodrigo Parra Novo (l'auteur du cafouillage selon les changelogs) n'est pas employé par Canonical mais un bénévole (la flemme de chercher la liste du personnel :p), il mérite une grosse fessée mais pas que tu dénigres autant son travail.

              Oh mais c'est pas le probleme. Le probleme c'est que ici tout le monde(a part les fans de Mandriva/Suse/...) ainsi que la fondation Ubuntu elle-meme s'amuse a dire "installez Ubuntu c'est aussi bien que Windows", mais quand on fait ca, faut assumer derriere hein, tu peux pas t'amuser a laisser 100'000 personnes installer ton OS et ensuite bacler tes updates n'importe comment au risque de tous les mettre dans la mouise.
              Alors soit on dit clairement qu'Ubuntu c'est un truc de hobbyiste et qu'il faut pas le mettre en production car il y a des risques de voir ses machines exploser en vol suite a un patch non teste, soit faut assurer derriere quand on sort les patchs.

            • [^] # Re: STOP !

              Posté par  . Évalué à 3.

              Peut-être même que Rodrigo Parra Novo (l'auteur du cafouillage selon les changelogs) n'est pas employé par Canonical mais un bénévole (la flemme de chercher la liste du personnel :p)


              En environ 15 secondes :
              https://wiki.ubuntu.com/RodrigoNovo

              C'est un employé de Canonical.

              • [^] # Re: STOP !

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

                Et même si ça n'était pas un employé, le boulot de la boite, c'est aussi de vérifier le boulot des bénévoles. Enfin, si tu donnes un accès aux updates en STABLE à un bénévole, tu en assumes les responsabilités quand tu prétends être une boite sérieuse qui vends du support par ailleurs.

                J'imagine bien MS dans la même situation : « Ah, non, mais on a donné le mot de passe root de jesaispasquoi-updates.microsoft.com à un inconnu, c'est lui qu'il faut tapper, pas nous ».

      • [^] # Re: Vitesse de réaction

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

        http://www.clubic.com/actualite-37472-correctif-problematiqu(...)

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 4.

          Le problème que je vois au 'bug' made in Ubuntu est l'impossibilité pour un utilisateur non averti d'accéder aux mises à jour qui vont corriger ça.

          Pour moi il y'a 2 choses qui ne devraient jamais casser : le réseau (pour la connection internet) et un accès simple aux mises à jour du système. Si un plantage de X conduisait à un petit menu ncurses simplissime je n'aurai rien à redire au problème actuel.

          Petit menu :
          - Mise à jour du système (sudo apt-get update dist-upgrade assume yes.... bref tout ce qu'il faut pour 0 interaction à part un mot de passe)
          - Autoconfiguration Xorg (comme à l'install bref tout ce qu'il faut pour 0 interaction à part un mot de passe)
          - Quitter (Ligne de commande)

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 2.

          Genial, compare la severite et specificite de ce bug la avec le cas present, il y en a un des 2 qui saute a l'oeil si tu fais un minimum de tests, l'autre qui est plus difficile a trouver.

          • [^] # Re: Vitesse de réaction

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

            Quand tu désinstalle IE 7 pour revenir a IE 6 et que tu as firefox installé , IE ne fonctionne plus en tant que navigateur Internet mais devient un wrapper pour firefox.


            C'est un bug volontaire ?

            • [^] # Re: Vitesse de réaction

              Posté par  . Évalué à 2.

              Aucune idee, IE7 est un soft en version beta, faut donc pas t'etonner si il y a des problemes avec mon cher, t'es prevenu avant d'installer la chose.

              • [^] # Re: Vitesse de réaction

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

                Oui une beta mais a chaque fois que tu ouvre IE 6, tu tombe sur une page te proposant d'installer IE 7.
                Et puis se bug se produit aprés la désinstallation de IE 7.
                Microsoft n'est pas capable d'ecrire un désinstalleur qui fonctionne ?
                Cela m'etonnerai ...

                Quoique c'est peut être fait exprés pour pousser les gens a utiliser IE 7 ou au moins à les empecher d'utiliser IE 6 sous windows xp :P

                • [^] # Re: Vitesse de réaction

                  Posté par  . Évalué à 2.

                  Oui une beta mais a chaque fois que tu ouvre IE 6, tu tombe sur une page te proposant d'installer IE 7.

                  Ah bon moi c'est marrant mais ca n'arrive sur aucune de mes machines, ca arrive peut-etre apres que t'aies installe IE7 j'en sais rien, mais ca serait presque normal la.

                  Microsoft n'est pas capable d'ecrire un désinstalleur qui fonctionne ?

                  C'est quelle partie des mots version beta que t'as pas compris ?

                  • [^] # Re: Vitesse de réaction

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

                    Ah bon moi c'est marrant mais ca n'arrive sur aucune de mes machines, ca arrive peut-etre apres que t'aies installe IE7 j'en sais rien, mais ca serait presque normal la.

                    Tu as un endroit où je pourrait te passer une image disque vmware ?
                    Faut ~1Go de place ...

                    • [^] # Re: Vitesse de réaction

                      Posté par  . Évalué à 2.

                      Fais meme plus simple, donne les etapes ici meme pour reproduire le probleme apres avoir installe un XP depuis le CD d'installation comme ca tout le monde pourra verifier.

        • [^] # Re: Vitesse de réaction

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

          J'avais jamais essayé le lancer de troll, c'est vrai que ça marche bien dis donc :-)

    • [^] # Re: Vitesse de réaction

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

      Félicitations pour la réactivité, mais il me semble qu'en moins de 12h, il y avait quand même un truc évident à faire, c'était virer cette putain de mise à jour, éventuellement remettre l'ancien paquet (en lui mettant un numéro de version supérieur par exemple), et prendre un peu son temps plutôt que de resortir un patch à l'arrache.

      Nan, parce que si je compte bien, le patch, il a été testé pendant 13 minutes et 17 secondes avant d'être envoyé aux utilisateurs.

      • [^] # Re: Vitesse de réaction

        Posté par  . Évalué à 2.

        Je suis d'accord sur la méthode (remettre l'ancienne version). Cependant, j'ai pas vu le patch (je l'aurais peut-être pas compris non plus), mais peut-être que le bug était vraiment "flagrant" et qu'il n'y avait pas trop à tester.
        Mais c'est vrai que dans ce cas, c'est encore plus gros qu'il soit passé dans les mises à jour, mais bon, ça peut toujours arriver.

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 4.

          mais peut-être que le bug était vraiment "flagrant" et qu'il n'y avait pas trop à tester.

          Ben justement, vu le bug que c'etait, c'est tout le contraire.

          Ce bug, qui empeche X de demarrer, ne pas l'avoir trouve avant que le package soit public, ca veut dire qu'ils n'ont fait _aucun_ test avant de le sortir, parce que quand tu fais un minimum de tests pour qqe chose comme X, tu vas evidemment tester sur qqe machines differentes avec les cartes du marche(donc au moins 1 ATI ou NVidia), et tu vas immediatement le voir vu que ce bug va empecher toute ta batterie de tests de tourner...

          Resultat, son petit fix la, si ca se trouve il corrige le probleme immediat, mais ca veut pas dire que le package est bon, car il pourait y avoir encore 10 autres problemes serieux dedans si ca se trouve, on en sait rien vu qu'ils n'ont pas fait de tests de regression sur le package !

        • [^] # Re: Vitesse de réaction

          Posté par  . Évalué à 4.

          Même si le bug est flagrant, en cas de problème, avant même de savoir si le bug est flagrant ou non, on revient TOUJOURS en arrière! C'est le BA B.A., et cela ne vaut pas que pour l'informatique de gestion (imagine un programme de traitement des retraits GAB qui merde ne serait-ce que 10 minutes en production, et qu'on laisserait tourner une demi-heure de plus "juste le temps de remonter le nouveau programme corrigé"!!!)

    • [^] # Re: Vitesse de réaction

      Posté par  . Évalué à 4.

      Je ne vois vraiment pas de quoi être fiers de ce correctif, mais alors vraiment pas. Je trouve la gestion de cette crise tout simplement déplorable.

      D'après la chronologie, entre l'identification du patch responsable du problème et la fermeture du bug, il ne s'est même pas écoulé un quart d'heure. Le nouveau paquet n'a donc pas eu le temps d'être testé correctement.

      C'était un bug grave, surtout pour une version stable. Même si le correctif pouvait sembler trivial et totalement sans danger, compte tenu de la gravité du bug, ça ne dispensait en aucun cas de tester soigneusement le nouveau paquet.

      Dès que le problème a été connu, la priorité aurait du être de limiter les dégats en revenant le plus vite possible à l'ancien paquet (de préfèrence en lui donnant un nouveau numéro) histoire de ne pas mettre plus d'utilisateurs dans la mélasse pendant qu'on cherchait le bug et qu'on préparait un correctif.

      Je pense que tout le monde sera d'accord pour dire que le bug initial est tout à fait excusable : Même les meilleurs font parfois des erreurs. Par contre, corriger un bug aussi grave en introduisant un correctif à la "vas y comme je t'y pousse" dans les dépots de stable, c'est lamentable.

  • # Pendant ce temps, chez Debian...

    Posté par  (Mastodon) . Évalué à 2.

    Sur la version unstable de xorg, il y a aussi quelques soucis...

    Un developpeur de la X Strike Force a malheureusement envoyé dans unstable un paquet qui devait aller dans experimental... Il s'agit de la version 7.1 de xorg, bientôt sur vos écrans, mais pas tout de suite.

    http://lists.debian.org/debian-devel/2006/08/msg01007.html

    • [^] # Re: Pendant ce temps, chez Debian...

      Posté par  . Évalué à 4.

      En même temps il n'a pas du y rester longtemps. Le message date d'aujourd'hui à 22h (GMT+1) et il n'y est déjà plus. Il fallait vraiment ne pas avoir de bol pour faire un dist-upgrade juste au mauvais moment.

    • [^] # Re: Pendant ce temps, chez Debian...

      Posté par  . Évalué à 3.

      En même temps, c'est la version "unstable", on sait quand même à quoi s'attendre un peu...

      Ceci dit, je ne pense pas qu'une seule distribution puisse se targuer de ne jamais avoir fait de boulette.

      De mémoire:

      debian: pb d'organisation dans les m-à-j de sécu., surcharge du dépôt sécu stable pdt une correction d'Xorg (ou était-ce encore XFree?? bon, toute façon, on s'en fout!)

      mandriva: destruction de lecteurs CD... ben oui, c'est peut-être pas de leur faute, m'enfin pour les gens qui ont paumé leur lecteur CD dans l'affaire, remboursé ou pas, ça emmerde un peu beaucoup sur le coup

      Et je suis sûr que les autres ne sont pas en reste. Maintenant, vu la trollogènabilité (oui, je viens de l'inventer...) d'ubuntu, je ne doute pas qu'on va en parler pendant des semaines, si ce n'est des mois...

      Tout le monde se calme, pas de panique!
      On verra bien les conséquences que ça a sur l'ensemble du parc ubuntu chez les non-experts!

      Si ça se trouve, Luce & Henri n'appliquent aucune mise à jour de sécurité donc ils n'auront absolument aucun problème!! :D

      -------->[wouah! fait chaud à Shanghai!!]

      • [^] # Re: Pendant ce temps, chez Debian...

        Posté par  . Évalué à 0.

        mandriva: destruction de lecteurs CD
        Si je me souviens bien, il y avait une manipe pour sauver les lecteurs CD en rade.

  • # La communauté lui pardonne

    Posté par  . Évalué à 2.

    Encore une fois, la communauté française a fait preuve d'un regard critique et d'une grande objectivité face à cette affaire. Morceaux choisis du forum ubuntu-fr :

    On fait tous des boulettes


    Il y a d'autres programmes qui se veulent pro et qui plantent beaucoup plus souvent.


    le serveur X est indépendant de Ubuntu


    Vous êtes pas content ?
    -> GO windows


    Dans le pire des cas, c le serveur X qui démarre plus, et alors ??!! ça se répare en 2-2


    L'erreur est humaine c pas non plus impardonnable faut arréter de dire ce qui aurait du ou non etre fait c tout


    Cela prouve que la distrib est vivante


    j'arrive toujours pas à comprendre cet archanement sur le programmeur qui a fait la bourde.
    Enfin je sais pas mais il ne me viendrait pas à l'esprit d'engueuler un ami ou ma femme parce-qu'elle casse mon verre de ricard préféré en faisant la vaisselle!!...

    Ben c'est pareil, faisez-là vous-même la vaisselle....


    Et enfin celle que je trouve excellente

    Quand je pense que des gens crèvent de faim dans le monde, qu'on fait la guerre ailleurs, et que la plupart des victimes sont des innocents n'ayant rien demandé de plus que de vivre en paix, et qu'on vient balancer son fiel parce qu'un développeur a fait une erreur - certes gênante - je trouve cela indécent.


    Et j'en passe...

    • [^] # Re: La communauté lui pardonne

      Posté par  . Évalué à 2.

      Et quand tu confonds la "communauté française" (?) et l'avis de quelques fans inconditionnels d'ubuntu, tu as un "regard critique et d'une grande objectivité". ?

      • [^] # Re: La communauté lui pardonne

        Posté par  . Évalué à 2.

        En effet, grossière erreure de ma part, j'ai été un peu trop vite.
        Il ne s'agit pas de toute la communauté française, mais celle d'Ubuntu-fr. Toutefois, je ne peux pas vraiment dire "quelques fans inconditionnels". Promène toi sur le topic concerné, tu verras qu'il s'agit de la quasi totalité des intervenants.

    • [^] # Re: La communauté lui pardonne

      Posté par  . Évalué à 5.

      sélection très critique de ta parts aussi, tu es journaliste à TF1 ?

Suivre le flux des commentaires

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