Rapporter un bug (FR)

Page traduite par la communauté

Note : Nous sommes actuellement quelques developpeurs actifs sur le projet. Nous ne pouvons pas répondre à chaque question ouverte, mais nous la lisons. Vos questions nous fournissent des retours d’informations importantes et nous vous en remercions, tout retour d’information est apprécié.

Configurez votre environnement

  • Soyez prêt pour une perte de données. Sauvegardez votre compte et liez votre compte à autant d’appareils que possible.

  • Installez la dernière version (ou même une version bêta) de Jami. Il est inutile de signaler des bugs sur les anciennes versions.

Comment signaler un bug (dysfonctionnement)

0. Créez un compte sur notre dépôt git (si ce n’est pas déjà fait)

1. Choisissez le bon projet dans lequel poster votre problème :

2. Si vous avez plusieurs problèmes, veuillez remplir des rapports de bogue séparés. Il sera beaucoup plus facile de suivre les bugs de cette façon.

3. Le titre est un résumé explicite du bogue (par exemple, la barre d’en-tête est trop grande en raison de la taille de l’icône).

4. Déterminez les étapes pour reproduire le bogue :

  • Si vous avez des étapes précises pour le reproduire - génial ! -vous êtes sur la bonne voie pour créer un rapport de bogue utile.

  • Si vous pouvez le reproduire occasionnellement, mais pas après avoir suivi des étapes spécifiques, vous devez fournir des informations supplémentaires pour que le rapport de bogue soit utile.

  • Si vous ne pouvez pas reproduire le problème, il n’est probablement pas utile de le signaler, à moins que vous ne fournissiez des informations determinantes sur son apparition.

  • Si le bogue conduit à d’autres bogues par la suite que vous ne pouvez pas reproduire d’une autre manière, il n’est probablement pas utile de le signaler.

5. Assurez-vous que votre logiciel est à jour. Idéalement, testez une version en cours de développement pour voir si votre bogue a déjà été corrigé.

6. Essayez d’isoler le problème de l’environnement et de le reproduire (pour ce-faire, testez-le sur différents appareils)

7. Décrivez votre/vos environnement(s) en précisant les éléments suivants :

  • la version du système d’exploitation

  • modèle précis de l’appareil (important pour les appareils mobiles)

  • si vous utilisez une version bêta

  • quelle version vous utilisez (de ring.cx, F-droid, Play Store, App store, votre propre version…). Si vous avez construit votre propre version de Ring, veuillez spécifier la version exacte de dring (LibRing ou Daemon) et la version du client (Vous pouvez l’obtenir avec dring -v et jami-gnome -v. Mais notez que nos paquets sont mis à jour assez souvent) et le commit Git.

  • les conditions du réseau : Les deux appareils sont-ils sur le même réseau local ? Des réseaux différents ? Est-ce qu’un ou les deux sont derrière NAT ? Utilisez-vous LTE ? Wifi ?

  • D’autres éléments si nécessaire : Fournisseur SIP, matériel…

Rédiger un résumé clair

Comment décririez-vous le bug en 10 mots environ ? C’est la première partie de votre rapport de bogue qu’un développeur verra.

Un bon résumé doit permettre d’identifier rapidement et de manière unique un rapport de bogue. Il doit expliquer le problème, et non la solution que vous proposez. Exemples :

Bon :) "L'annulation d'un transfert de fichier fait planter Ring"
Pas bon :( "Le logiciel se plante"
Bon :) "Tous les appels raccrochent après 32 secondes"
Pas bon :( "Impossible d'appeler mes amis"

Rédiger des étapes précises à reproduire

  • Comment un développeur peut-il reproduire le bogue sur son propre appareil ?

Les étapes à reproduire sont la partie la plus importante de tout rapport de bogue. Si un développeur est capable de reproduire le bogue, il est très probable que le bogue soit corrigé. Si les étapes ne sont pas claires, il n’est même pas possible de savoir si le bogue a été corrigé. Nous sommes tout à fait conscients que certains bogues peuvent vous sembler évidents, mais ils sont probablement liés à votre environnement. Plus vous serez précis, plus vite le bogue sera corrigé.

  • Que devez-vous inclure dans un rapport de bug ?

Indiquez si vous pouvez reproduire le bogue à volonté, occasionnellement ou pas du tout. Décrivez votre méthode d’interaction avec Ring en plus de l’intention de chaque étape. Après vos étapes, décrivez précisément le résultat observé (réel) et le résultat attendu.

Séparez clairement les faits (observations) des spéculations (suppositions).

Bon :)

Je peux toujours reproduire en suivant ces étapes :

1. Démarrez Ring en cliquant sur l'icône du bureau
2. Commencez une nouvelle conversation avec n'importe qui
3. Cliquez sur l'icône de transfert de fichiers

Résultats attendus : Une fenêtre s'ouvre et me demande de choisir un fichier à envoyer.
Résultats réels : Lorsque je clique sur l'icône de transfert de fichiers, rien ne se passe.

Pas bon :(

Essayer de transférer un fichier
Cela ne fonctionne pas.

Résultat obtenu

Veuillez inclure :

  • Les journaux de débogage du daemon (ou LibRing) et du client.

  • Le core dump s’il a été produit.

Résultat attendu

Il s’agit d’une description du comportement attendu ou souhaité.

Fournir des informations supplémentaires

Les informations suivantes sont demandées pour la plupart des rapports de bogue. Vous pouvez gagner du temps en fournissant ces informations sous la rubrique Résultats attendus.

Journaux

Client-qt (Windows, GNU/Linux)

Allez dans les paramètres généraux. Dans la section “Dépannage”(Déverminage, Débogage), vous pouvez cliquer sur “Ouvrir les journaux”, où vous pourrez obtenir des statistiques (“Show stats”) ou commencer à enregistrer des informations via “Journaux reçus”. Ensuite, vous pouvez simplement copier le résultat et expliquer votre scénario.

Sur GNU/Linux

Journaux classiques (par défaut, seuls les journaux >= warning sont journalisés) :

journalctl --since "24h ago" | grep dring

Journal complet : Puisque l’interface graphique et le démon Ring sont des processus séparés, la manière la plus simple d’obtenir les journaux des deux est de les démarrer un par un, manuellement.

  1. Assurez-vous qu’aucune instance du client ou du daemon Ring ne fonctionne avec `ps aux | grep ring``.

    • Ring peut être en cours d’exécution même si aucune fenêtre n’est ouverte, selon vos préférences.

    • Si un client ou un daemon est en cours d’exécution, tuez-les avec kill PID.

  2. Sur un terminal, démarrez le démon avec dring -d -c.

    • Cet exécutable n’est normalement pas dans le PATH, et sur les paquets Ubuntu, il est situé dans /usr/lib/x86_64-linux-gnu/dring -d -c ou /usr/lib/ring/dring -d -c.

  3. Dans un autre terminal, démarrez le client avec (voici un exemple pour Gnome) jami-gnome -d.

Pour obtenir un backtrace, vous pouvez exécuter le programme dans gdb :

̀ gdb -ex run jami-gnomeougdb -ex run –args /usr/lib/ring/dring -cd`.

Lorsqu’il se plante, vous pouvez taper bt puis appuyer sur Enter. Et copiez le backtrace sur le problème. (ou thread apply all bt, c’est encore mieux)

Sur Mac OS

Naviguez jusqu’à /Applications/Jami.app/Contents/MacOS/

  • Double-cliquez sur Jami. Cela lancera Jami et imprimera le journal dans le terminal.

  • Copiez le journal du terminal vers un fichier.

Sur Android

  • Vous devez avoir configuré adb sur votre ordinateur.

  • Lancez Ring sur votre smartphone et exécutez ensuite

  • adb logcat *:D | grep `adb shell ps | egrep 'cx.ring' | cut -c10-15` > logring.txt

  • Vous avez maintenant un fichier contenant le log du client

Pour Windows

Ouvrez un terminal(cmd.exe) et lancez Jami.exe avec les options suivantes :

  • -d pour ouvrir une fenêtre console séparée pour recevoir les logs

  • -f pour écrire les journaux dans %localappdata%\jami\i.log

  • -c pour imprimer les journaux directement dans la fenêtre de sortie de débogage de Visual Studio.