J'ai un Acer Timeline 1830T. Lorsque j'installe les versions 10.10 et 11.04, il doit disposer du module Acer-wmi
: liste noire pour que le sans-fil fonctionne .
Je pense que je dois déposer un bogue sur le noyau Linux mais je ne suis pas sûr. J'ai entendu parler du terme "bizarrerie" utilisé par les développeurs lorsqu'il est question de réparer quelque chose de telle sorte qu'il fonctionne sur certains matériels.
Est-ce bien un bug du noyau? Quelles mesures dois-je prendre pour que cela soit signalé de manière à ce que toutes les personnes utilisant mon ordinateur portable n'aient pas à passer par là à maintes reprises?
Ceci est un bogue du noyau¹, vous voudrez donc utiliser ubuntu-bug linux
dans un terminal. Vous voudriez alors modifier le rapport de bogue créé pour ajouter que vous devez ajouter la liste noire Acer-wmi
comme solution de contournement pour le chipset sans fil ne fonctionnant pas comme prévu.
¹ Techniquement, il ne s’agit pas d’un bogue du noyau, mais bien d’une combinaison de matériel, de BIOS et de pilotes de noyau défectueux. En revanche, il peut probablement être piraté dans le noyau, d’où la mauvaise utilisation du "bogue du noyau". "
Si vous voulez que cela aille n'importe où, ne pas just == enregistrer un bogue . Bien sûr, vous devriez créer un bogue sur Launchpad, mais ce n’est vraiment que le début du processus de quelque chose d’amont inhérent à cela.
Découvrez ce que ça fait
Regardez le code découvrez ce qu'il est censé faire. Si vous n'en avez pas besoin, pourquoi est-ce là? Est-ce que quelque chose d'autre fait son travail maintenant? Si c'est quelque chose qui est toujours en demande, pourquoi ne fonctionne-t-il pas pour vous?
Vous verrez souvent des logiciels spécifiques au matériel écrits pour les cas Edge comme une seule gamme d’ordinateurs portables (par exemple, il existe des dizaines de pilotes matériels Thinkpad).
Selon son fichier readme , le pilote couvre le sans fil, les DEL, le bluetooth, la 3G et le rétroéclairage. Pour moi, cela ressemble à quelque chose que vous (ou d'autres) voudriez peut-être, il serait donc peut-être inutile de le transférer ou de le placer sur une liste noire.
Découvrez comment il s'est installé sur votre ordinateur
D'où vient-il? Est-il tiré dans le noyau? Est-ce une traction Ubuntu? Ce sera finalement décider où vous devez déposer votre plainte.
Avec les problèmes au niveau du noyau, il est vraiment utile de tester le dernier noyau Vanilla stable. Vous pouvez récupérer une copie de le référentiel principal bien que vous constatiez probablement que la version de GCC ne concorde pas avec certains pilotes binaires (je l'ai avec nvidia), vous ne voudrez donc pas l'exécuter. sur tout le temps IMO.
Si le problème persiste avec un noyau Vanilla, ajoutez un bogue en amont, associez-le au bogue du tableau de bord et suivez-le également. Un bogue Nice en double lien aidera tout le monde à rester sur la même page.
Dans ce cas, cela ressemble à un pilote de noyau dans l’arbre (c’est-à-dire que sa source est extraite du référentiel du noyau et intégrée).
Trouvez la ou les personnes responsables
Il n’est pas raisonnable de simplement renvoyer un bogue sur Launchpad et d’espérer qu’il trouve la bonne personne. Je dirais que seulement une petite partie des développeurs suivent leurs bogues, vous devez donc trouver les responsables du logiciel et les contacter.
Il peut sembler impoli de commencer à envoyer des courriels à des personnes, mais le logiciel est leur bébé. Si cela ne fonctionne pas, je pense qu'ils aimeraient le savoir. Neuf fois sur dix, ils vous aideront également à identifier le problème.
S'il est toujours maintenu, obtenez les instructions de débogage. Vérifiez que votre matériel est compatible.
S'il n'est pas maintenu, et que vous pouvez le confirmer avec l'ancien responsable, créez un bogue dans le noyau pour avertir les utilisateurs qu'une partie du code pourrit et cause des problèmes.
Proposer des actions aux bonnes personnes
Lorsque vous savez quel est le problème, ne le gardez pas pour vous. Assurez-vous de prendre des mesures sur vos insectes.
Si c'est quelque chose qui peut être corrigé dans le pilote, poursuivez les utilisateurs du noyau pour obtenir la nouvelle version dans la version de développement. Demandez-lui de le reporter à 2.6.35 pour les utilisateurs Ubuntu existants. Discutez avec l’équipe du noyau de la possibilité d’introduire les modifications dans le noyau de Maverick (même si vous n’avez peut-être pas de chance).
En cas de pourriture, incitez les principaux développeurs du noyau à le transférer de leur référentiel. Demandez aux développeurs de l’équipe de noyau Ubuntu de le supprimer de leur repo. À tout le moins, demandez qu’il soit sur une liste noire (comment certains modules ont été supprimés de force par Ubuntu dans le passé).
Si vous obtenez un bon retournement sur la réparation/destruction du pilote, il sera devrait == obtenir le correctif dans le dernier noyau Natty (qui est toujours au stade -next
du bon repo de noyau).
Ce que j'essaie de faire comprendre, c’est lorsque vous faites votre propre tri et que vous parlez aux bonnes personnes, les choses attirent beaucoup plus d’attention et ont une plus grande chance d’obtenir un bon résultat final.
Et ne vous arrêtez jamais si vous voyez une autre personne avec le même problème. Abonnez-vous-y, commentez leur bogue, demandez ce qu'ils ont trouvé, demandez-leur ce qu'ils ont fait à ce sujet… Et continuez ensuite. Ne comptez pas sur eux pour résoudre votre problème.
C’est ainsi que l’Open Source est censé fonctionner. Collaboration par une bonne communication ouverte. Communiquez bien votre problème, aidez là où vous le pouvez et vous avez de bonnes chances d’obtenir un logiciel de meilleure qualité.
En tant que membre de l’équipe du noyau Ubuntu, plus précisément en tant que "gars du bogue du noyau", je suis d’accord avec réponse de Daniel car c’est la somme de ce que les ingénieurs voient comme un problème. Ce n'est pas à écarter réponse d'Oli .
En ce qui concerne l’utilisateur final hautement technique, la réponse d’Oli est tout à fait vraie, c’est un ensemble des étapes auxquelles on pourrait s’attendre de la part d’une personne dotée d’un savoir-faire technique considérable, mais de notre intention (et de l’objectif même de ce site). est de guider le moins technique.
Notre objectif principal doit être de leur fournir des réponses rapides et précises leur permettant de continuer à utiliser les logiciels que nous développons. Mon dicton préféré est: "Si ce n'est pas simple, ils ne le feront pas." Les 'ils' ici se référant à qui que ce soit l'utilisateur est à l'époque.
Cela dit, et compte tenu de mon admiration personnelle pour la complétude de votre message Oli, je dois être honnête et dire qu’il ya très peu de lecteurs de ce site qui liront tout. Ils ne liront probablement pas tout le mien, et ça va.
En fin de compte, la réponse de Daniel est exactement ce dont nous avons besoin ici. Cela transmet à la fois mon impression et celle de l'équipe sur ces problèmes, ainsi que la méthode que nous préférons aborder.