Journal Signaler un bug sur la kernel list ?

Posté par  .
Étiquettes : aucune
10
7
août
2009
Tout d'abord bonjour!

Ça fait plusieurs mois/années que je n'ai pas écrit ici ... mais bon on est vendredi ca peut m'aider!

Bon alors depuis quelques temps je rencontre quelques problèmes avec le noyau lui même (non ca ne peut pas être ma distribution étant donné que c'est une "Daibihen!" :-p )

Mais je ne sais pas du tout comment poster ces bugs "facilement" sur la kernel list ?

du style:
- Lorsque le module sky2 est utilisé (cad: traffic en dl ou ul ), et que l'on essaye de faire un pm-suspend .... crabadaboum, un kernel panic! (oui je sais il existe SUSPEND_MODULES=, mais bon c'est juste bon pour bricoler ça...)

- Avec un pm-hibernate ... pas moyen de redémarrer le pc .. obliger d'enlever la pile du bios!
7vis, le clavier, et un bout de la coque pour redemarrer le pc.. on a fait plus rapide en terme de démarrage de pc ...

- mpd qui me crache à la figure lors d'un démarrage de celui-ci si le répertoire des fichiers musicaux se trouve sur un volume monté avec cifs (vu avec les dévellopeurs de mpd ... c'est pas eux qui seraient en cause mais bien le module cifs ...)

- Lorsque j'essaye d'envoyer un fichier bluetooth vers mon téléphone ... Kernel Panic ... alors que dans l'autre sens ça fonctionne parfaitement.

- Pleins d'autres petits trucs bien particuliers ...

A oui j'utilise depuis 2000/2001 un noyau vanillia (donc commence à connaitre les options) et en ce moment c'est le 2.6.31-rc5 qui fonctionne chez moi.

Donc même si je suis conscient qu'il y a pleins de petits bugs, comment les remonter de manière facile à la team kernel.org ? (sans avoir à lire 400Mails/heures en m'inscrivant a une mailing list)

Merci d'avance.

  • # humhum ...

    Posté par  . Évalué à 4.

    méa-culpa, me croira qui voudra!

    Hier encore en tapant sur google des trucs comme 'kernel bug linux' etc ... je n'avais rien de concluant ...

    a l'instant même un 'kernel bug' me renvoie un joli http://bugzilla.kernel.org/ ...

    Bon lien ?

  • # Comme n'importe quel projet normal...

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

    Bonjour,

    Tu utilise le bugtracker qui se trouve être un bugzilla dans ce cas.
    http://bugzilla.kernel.org/

    Et on va probablement aussi te dire que ce genre de topic a plus sa place dans les forums que dans un journal.

    Bon week-end,

    • [^] # Re: Comme n'importe quel projet normal...

      Posté par  . Évalué à 1.

      Ici je ne cherche pas à corriger les problèmes cités (qui aurait eu sa place dans les forums je te l'accorde)

      Mais plus simplement à savoir comment vous faites pour remonter un bug de manière facile sur des "gros projets"

      Car oui comme n'importe quel projet 'normaux' avec une poignée de developpeur il est très facile de remonter de simples bugs avec un bugzilla et quelques paroles sur irc/mail avec ledit auteur du projet pour corriger ceux-ci...
      Mais il en est tout autre avec des projets qui font quelques millions de lignes et quelques milliers de devellopeurs.

      Cordialement,

      • [^] # Re: Comme n'importe quel projet normal...

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

        Je ne vois pas en quoi le fait que le projet soit gros change quoi que ce soit par rapport à l'utilisation d'un logiciel genre Bugzilla ou autre BTS.

        Lors de ton rapport, tu spécifie le composant impacté (tu doit pouvoir dire que ça touche telle ou telle partie du Kernel, ici tu identifie quand même assez bien le problème) et ça envoie un email à une mailing list avec les personnes responsables qui iront ensuite regarder ton rapport.
        C'est comme ça que ça marche normalement, je vois pas ou est le problème avec un gros projet, tu as juste des sous composants (pareil pour KDE et GNOME par exemple).

        • [^] # Re: Comme n'importe quel projet normal...

          Posté par  . Évalué à 3.

          C'est surtout que j'avais pris pour habitude de "déranger" personnellement les responsables des logiciels lorsque je trouvais des petits bugs (non kde/gnome/openoffice.org/firefox/kernel)

          Les logiciels maintenu par 1 à 10 personnes sont plus facilement 'joinable' par irc/jabber pour expliquer le problème plus particulièrement et le résoudre facilement (toute les données d'un coup).

          Un autre exemple, lors d'une copie de fichiers de cifs à ext4, un e2fsck me montre 'non-contiguous files (64.9%)', c'est un problème de cifs ou ext4 ? bien plus compliqué sur le bugzilla de choisir si c'est telle ou telle module qui est responsable alors qu'en 'live' le problème est beaucoup plus facile à expliquer et à assigner/corriger.


          Finalement j'ai quand même une réponse:

          Bugzilla.kernel.org tout simplement ... même je ne trouve pas cette idée particulièrement efficace pour certains problèmes, mais si tout le monde fait comme ça c'est qu'il doit y avoir une raison ;)

          • [^] # Re: Comme n'importe quel projet normal...

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

            Bah déjà c'est normalement pas n'importe quel utilisateur neuneu qui va rapporter des bugs.
            Ensuite, si ton rapport est suffisamment claire (notamment sur la façon de le reproduire) alors les développeurs pourront le réassigner, si nécessaire, au composant qui pose réellement problème.

            Note aussi que tu peut toujours entrer en contact avec ces personnes (par irc/jabber suivant les disponibilités des gens) une fois ton rapport de bogue effectué puisque tu verra directement dans le rapport qui te répond, en théorie, rien ne l'empêche.

          • [^] # Re: Comme n'importe quel projet normal...

            Posté par  . Évalué à 2.

            Le bugzilla est plus utilisé comme un moyen de tracking que comme une source de rapports de bug. Le plus efficace reste le mail à la LKML. Pas besoin d'être abonné, la pratique veut que toutes les personnes concernées restes en Cc:. Et il ne faut pas avoir peur, les discussions avec les bug-reporters sont normalement cordiales.

            Par contre envoyer un mail par problème et essayé de cibler les destinataires en fonction du sous-système (voir le fichier MAINTAINERS) est une bonne pratique. Pour ton problème avec MPD, il serait certainement bon de mettre en CC (avec son accord) le ou les devs de MPD qui disent que c'est un problème noyau.

            • [^] # Re: Comme n'importe quel projet normal...

              Posté par  . Évalué à 3.

              Ce que tu rapportes ici est bon à entendre/lire: pas besoin d'être abonné à la LKML pour envoyer des problèmes par mail... Cool ça alors de garder les personnes concernées par Cc:!

              Ça va bug-reporters sec alors avec le/les bonnes personnes concernées ;)

              merci

          • [^] # Re: Comme n'importe quel projet normal...

            Posté par  . Évalué à 2.

            Si tu veux envoyer un mail à la ML du kernel sans t'y abonner, envoie-le et demande à être en CC ...

  • # je vais dire une betise mais

    Posté par  . Évalué à 6.

    tu as un kernel en :
    - branche developpement : 2.6.31
    - qui n'est pas totalement finalisé : RC

    ca fonctionne avec le kernel precedent ?
    2.6.30-stable ?
    2.6.28 ?

    parce là pour le coup ca fait beaucoup de bug dans pas mal de sous-systeme

    • [^] # Re: je vais dire une betise mais

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

      Heu la "branche développement" ca n'existe pas...
      Le 2.6.31 sera aussi stable que le 2.6.30 (ou plus, ou moins... :) )
      (Le noyau supporté à long terme actuellement c'est le 2.6.27)

    • [^] # Re: je vais dire une betise mais

      Posté par  . Évalué à 1.

      Pour la plupart des bugs cités ils étaient valables avec les précédentes versions aussi..
      (sauf le bug avec mpd qui n'apparaissait pas avant)

      J'ai essayé la RC car j'avais quelques heures/jours à perdre pour le noyau et essayer de signaler ces bugs présent.

      Par contre je ne vois pas pourquoi une RC ne serait pas 'stable', oui certaines branches sont très 'instable' voir ne fonctionne plus car en cours de grosses modifications mais normalement le 'coeur' est censé fonctionner autant, voir plus que la version précédente.

Suivre le flux des commentaires

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