Que se passe-t-il une fois que `ubuntu-bug` a fait son travail?

Jusqu'à il y a quelque temps, vous avez exécuté apport-bugou ubuntu-bugcommencé à signaler un bogue. Le système ouvrirait alors le tableau de bord avec votre compte, téléchargerait les informations collectées et vous permettrait d'ajouter plus d'informations au rapport de bogue.

Maintenant, lorsque je lance gksudo ubuntu-bug(par exemple avec un crash-file comme argument), la boîte de dialogue de bogue commune apparaît

et c'est tout.

Où le rapport est-il envoyé? Certainement de ne pas lancer le tableau de bord comme rapport de bogue (bien que dans la situation concrète, les gens aient pu déposer un rapport sur ce bogue).

Donc: où est envoyé ce rapport (et peut-être juste) comment puis-je toujours déposer un rapport de bogue depuis mon système (facilite le téléchargement des fichiers concernés)

Se pourrait-il que "le système" ait décidé qu'il s'agirait d'un doublon d'un bogue déjà existant?

Techniquement, ubuntu-bugenregistre simplement le rapport de plantage localement. Un programme distinct whoopsiesurveille les rapports enregistrés et les télécharge dans une base de données centrale, où ils sont automatiquement regroupés pour identifier les problèmes globaux.

Les données résultantes sont affichées sur le tracker d'erreur Ubuntu :

Les tendances agrégées sont accessibles au public et les détails du rapport sont disponibles pour les développeurs de confiance. Plus de détails sont disponibles sur le wiki Ubuntu .

Par défaut, ubuntu-bugn'ouvre pas les bogues sur Launchpad pour les rapports d'erreur dans les versions stables, mais vous pouvez le configurer si vous le souhaitez. Après avoir effectué cette modification, vous pouvez ouvrir un bogue pour un rapport d'incident existant en exécutant ubuntu-bug /var/crash/foo.crash.

Les informations ou le rapport collectés sont téléchargés vers un système de suivi des bogues.

Si un processus du système meurt en raison d'un signal qui est communément appelé un `` crash '' (violation de segmentation, erreur de bus, exception à virgule flottante, etc.), ou par exemple une application Python empaquetée lève une exception non interceptée, le backend répart est invoqué automatiquement.

Il produit un rapport de crash initial dans un fichier dans / var / crash / (le nom du fichier est composé du nom de l'exécutable crashé et de l'ID utilisateur). Si le processus en panne appartient à l'utilisateur actuellement connecté, ou s'il appartient à un processus système et que l'utilisateur est un administrateur, répartit informe l'utilisateur de la panne et propose de signaler le problème.

Si l'utilisateur laisse la case "Envoyer le rapport d'erreur" activée, Apport télécharge les informations collectées dans le système de suivi des bogues. Après cela, il ouvre la page de dépôt de bogues des packages avec un titre de bogue par défaut et laisse le reste du processus de dépôt de bogues à l'interface utilisateur Web.

Ubuntu reçoit chaque jour un nombre incroyablement élevé de rapports de bogues via notre système de suivi des bogues. Chacun de ces éléments doit être lu, évalué et trié afin de pouvoir être corrigé. C'est là que nous pourrions utiliser votre aide pour aider avec les bugs. Pour une représentation visuelle du processus de triage des bogues, consultez ces beaux organigrammes.

Chaque rapport de bug est une conversation avec le journaliste. Le premier contact qu'un journaliste a généralement avec la communauté Ubuntu est par le biais d'un trieur de bogues, qui essaie de rédiger un rapport de bogue complet. Il est très important que nous donnions une bonne impression, alors soyez poli et essayez d'utiliser votre meilleur anglais.

Travailler sur des bogues simples et non triés est un bon moyen de commencer et de se familiariser avec la procédure de tri, car vous devrez gérer tous les aspects du cycle de vie d'un bogue. La section Bogues non triés explique où les trouver.

Types de bogues

Rapports d'apport

Les rapports Apport sont des bogues signalés via le programme automatisé de rapport de bogues Apport. Signaler des bogues en utilisant Apport est le moyen préféré de signaler un bogue car il donne aux développeurs beaucoup d'informations sur le système affecté. Lorsque Apport est utilisé, moins d'informations supplémentaires sont nécessaires, ce qui accélère l'ensemble du processus.

Vous pouvez reconnaître ces bogues par la liste ajoutée d'informations système dans leur description. Certains programmes ont des crochets pour Apport, ajoutant plus d'informations lors du signalement d'un bogue. Ces informations se trouvent généralement dans les pièces jointes.

Bogues confirmés

Lorsqu'un bogue est marqué comme «Confirmé», il n'est pas encore entièrement trié. Ce bogue est très proche d'être marqué comme «Trié», mais vous devez vous assurer qu'il est prêt à être corrigé par les développeurs.

Requêtes de nouvelles fonctionnalités

Si le rapport de bogue est en fait une demande de fonctionnalité, il existe deux possibilités. Si l'amélioration demandée est petite et bien définie et / ou si la suggestion concerne un projet en amont, l'importance du bogue doit être définie sur «Liste de souhaits». Une fois le rapport terminé, le statut doit être réglé sur «Trié».

Seuls les membres de l'équipe Ubuntu Bug Control peuvent le faire. Si vous n'êtes pas membre, vous devrez demander à quelqu'un qui le fera pour vous. Collez le numéro de bogue dans # ubuntu-bugs et dites que vous pensez que le bogue devrait être réglé sur «Liste de souhaits». Quelqu'un le remarquera et le réglera pour vous, mais pas nécessairement immédiatement.

Comment ça marche en interne?

Interception de crash

Apport utilise / proc / sys / kernel / core_pattern pour diriger directement le vidage de mémoire dans la répartition:

$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
$ 

Remarque: même si ulimit est défini sur les fichiers de base désactivés (en spécifiant une taille de fichier de base de zéro à l'aide de ulimit -c 0), répart capturera toujours le plantage. Pour intercepter les plantages Python, il installe un /etc/python*/sitecustomize.pyattribut d'appel sur les exceptions non gérées.

Exemple

Apport est même capable de capturer les fichiers principaux si le PID 1 (Upstart) meurt:

1. Si Upstart détecte une incohérence interne, il augmente le signal SIGABRT.
2. Le gestionnaire de crash d'Upstart est appelé sur SIGABRT.
3. Le gestionnaire de crash Upstart lance un processus enfant.
4. Le processus enfant Upstart relance le signal, ce qui entraîne une sortie anormale de l'enfant.
5. Le noyau détecte que le processus enfant s'est terminé de manière anormale et appelle répart, en redirigeant le fichier principal vers les entrées standard (en raison de / proc / sys / kernel / core_pattern).
6. alloc écrit le fichier core sur le disque dans / var / crash /.
7. Le PID 1 attend la fin de son enfant (ce qui ne se produit qu'une fois que proportion a fini d'écrire le fichier principal).
8. PID 1 se ferme.
9. panique du noyau.
10. Au prochain démarrage, Whoopsie détectera le fichier de plantage et le traitera.

Backend

Afin de maintenir le retard et l'impact CPU / IO aussi bas que possible, /usr/share/apport/apportne collecte que les données qui doivent être acquises pendant que le processus bloqué existe toujours: informations de /proc/pid, vidage de mémoire, chemin exécutable et numéro de signal. Le rapport est écrit à /var/crash/executable_path.uid.crash.

Invocation frontend

Dans Gnome, update-notifier maintient une veille inotify /var/crash. Chaque fois qu'il y a quelque chose de nouveau, il appelle / usr / share / répart / répart-checkreports. S'il y a de nouveaux rapports, il appelle / usr / share / répart / répart-gtk, qui est l'interface montrée dans les captures d'écran ci-dessus.

Le frontend collecte ensuite des informations supplémentaires telles que les versions de package, les sommes de contrôle des fichiers de package ou la version du système d'exploitation, et appelle tous les hooks de package correspondants. Pour désactiver cela, vous pouvez exécuter gsettings set com.ubuntu.update-notifier show-proportion-crashes false (en tant qu'utilisateur de bureau ordinaire).

Auto-retracer basé sur le tableau de bord

Le centre de données canonique exécute un service qui retrace automatiquement les bogues avec proportion. En marquant les bogues selon l'architecture dans Launchpad, une trace sera effectuée et la balise sera supprimée. Les balises utilisées sont need-i386-retrace ou need-amd64-retrace. Voir l'annonce.

Crochets Apport par emballage

Il est possible pour les packages de spécifier les informations collectées à partir du système et incluses dans le rapport de bogue. Cela se fait par des crochets de répartition contenus dans les packages. Pour des exemples utiles, voir:

• source_xorg.py - ajoute des fichiers journaux et des détails matériels supplémentaires aux rapports de bogues
• usplash - ignore les plantages dans des chemins de code spécifiques
• source_totem.py - pose des questions au journaliste et recueille différentes informations en fonction des réponses

dans / usr / share / proportion / package-hooks. Il existe également une liste de packages fournissant des crochets de répartition.

Si un rapport de plantage ou de bogue est soumis via alloc, les hooks appropriés seront exécutés automatiquement. Si vous avez un bogue déjà signalé qui a été déposé sans attribuer et que vous êtes intéressé par les informations de ces hooks, vous pouvez demander au rapporteur de bogue d'utiliser le numéro de bogue d'allouer-collecter.

Utilisez la source, Luke!

• Vous pouvez télécharger l'archive tar en amont à partir de la page du projet Launchpad, ou l'archive source Ubuntu à partir de l'archive Ubuntu.
• alloc est développé avec le bazar RCS sur Launchpad. Si vous souhaitez y contribuer ou développer votre propre système sur cette base, vous pouvez obtenir votre propre branche avec bzr get lp: répart pour le tronc, ou debcheckout -a répart pour la branche de packaging Ubuntu.

Plans futurs

Diverses améliorations des performances, de meilleurs outils pour travailler avec les rapports et l'intégration de plus de langages (traces de pile Mono / Python, messages d'assertion, etc.) Voir la spécification pertinente.

^{Sources: Apport , Comment trier et Comment activer Apport}