 |
Autres langues Deutsch ; English ; français ; |
| Résumé : Cette page a pour but de donner quelques conseils aux nouveaux membres. Il peut être difficile de savoir par où commencer, surtout si vous n’avez jamais vu un paquet auparavant. C’est un endroit où nous pouvons partager nos trucs et astuces et faciliter les tests d’AQ pour Mageia pour les nouveaux (et anciens !) membres. Si vous pouvez l’améliorer, nous vous encourageons à le faire. |
Contents
Le wiki
Le premier endroit à regarder est ici même sur le wiki. Vous trouverez des liens vers les procédures de test sur le portail de l’équipe AQ. Idéalement, nous devrions les remplir plus souvent, cela pourrait devenir une ressource précieuse. Seules quelques-unes ont été ajoutées jusqu’à présent, mais si vous lisez ceci et que vous recherchez une procédure, veuillez envisager de l’ajouter lorsque vous en trouverez une. N’importe qui avec une identité Mageia est apte à éditer le wiki, c’est-à-dire toute personne qui peut se connecter sur les forums ou bugzilla par exemple. Une identité Mageia permet de joindre n’importe quel site Mageia.
Bugzilla – Pages man – Qwant
Un bon point de départ lorsque vous cherchez un moyen d’évaluer un paquet est de rechercher dans bugzilla pour voir comment cela se faisait auparavant. Tout n’y sera pas, bien sûr, mais il y a des paquets qui reçoivent des mises à jour fréquemment et le fait de regarder les mises à jour précédentes donne généralement une bonne idée de la procédure à suivre pour tester aussi cette mise à jour.
Vous pouvez rechercher les bogues fermés relatifs au paquet que vous voulez tester. Il est plus facile de le faire en cliquant sur le bouton Search avec la loupe, de bugzilla plutôt que de simplement l’entrer dans le champ de recherche. En utilisant le champ Simple Search, sélectionnez simplement Closed comme statut. Vous pouvez également sélectionner Mageia pour le Product, pour affiner la recherche.
Pensez aussi aux pages man et Qwant.
| $ man <package> |
Vous constaterez parfois que lorsqu’une page du manuel manque, vous pouvez utiliser la commande que vous voulez tester, avec l'instruction --help à la fin. Par exemple,
| $ man --help |
URPM – quoi ?
Les outils Urpm sont très puissants. Il y a beaucoup d’options disponibles, mais seulement un petit sous-ensemble dont nous devons nous préoccuper en matière d’Assurance Qualité. Vous trouverez ici de nombreuses informations sur les différents outils. La page vaut la peine d’être lu. Vous pouvez également vérifier les pages de manuel pour chacune d’elles. Par exemple :
| $ man urpmi |
Alias utiles
Voici quelques alias que vous pourriez trouver utiles lors de l'exécution de tâches d'AQ.
Ces alias doivent être placés dans le fichier /root/.bashrc
Après les avoir ajoutés, vous devrez vous déconnecter et vous reconnecter.
Si vous en connaissez d'autres qui pourraient être utiles à d'autres, n'hésitez pas à les ajouter !
| # Alias AQ pour activer, désactiver et mettre à jour les médias "core", " non-free ", "tainted" et "updates testing". alias ecupdt='echo -e "Activation Core Updates Testing\n" && urpmi.update --no-ignore "Core Updates Testing"' alias dcupdt='echo -e "Désactivation Core Updates Testing\n" && urpmi.update --ignore "Core Updates Testing"' alias cupdt='echo -e "Réactualisation Core Updates Testing\n" && urpmi.update "Core Updates Testing"' alias enfupdt='echo -e "Activation Nonfree Updates Testing\n" && urpmi.update --no-ignore "Nonfree Updates Testing"' alias dnfupdt='echo -e "Désactivation Nonfree Updates Testing\n" && urpmi.update --ignore "Nonfree Updates Testing"' alias nfupdt='echo -e "Réactualisation Nonfree Updates Testing\n" && urpmi.update "Nonfree Updates Testing"' alias etupdt='echo -e "Activation Tainted Updates Testing\n" && urpmi.update --no-ignore "Tainted Updates Testing"' alias dtupdt='echo -e "Désactivation Tainted Updates Testing\n" && urpmi.update --ignore "Tainted Updates Testing"' alias tupdt='echo -e "Réactualisation Tainted Updates Testing\n" && urpmi.update "Tainted Updates Testing"' |
Urpmq est votre ami
| $ urpmq -i <package> |
Urpmq peut se passer des privilèges root. Il peut être exécuté en tant qu’utilisateur normal, d’où le signe $, que vous verrez dans la console lorsque vous vous connecterez. C’est une notation courante et vous la verrez tout au long du wiki. Une commande exécutée en tant que root sera précédée du signe #, qui est l’invite root.
Cette commande affiche des informations utiles sur un paquet, y compris une description, le RPM source et l’architecture (i586, x86_64 ou noarch) et le groupe, ce qui peut vous donner une idée de son utilisation.
| $ urpmq –whatrequires <package> |
En utilisant –whatrequires vous obtiendrez une liste des paquets qui nécessitent le paquet que vous recherchez. Ceci peut être utile s’il est difficile de tester directement le paquet mis à jour. Vous pouvez ensuite utiliser un paquet qui utilise ce paquet, pour le tester. C’est souvent utile lors du test des bibliothèques.
| $ urpmq –whatrequires-recursive <package> |
Celle-ci retourne une liste des paquets qui nécessitent le paquet que vous avez recherché ainsi que tous les paquets qui le demandent. La liste peut être assez longue ! Mais aussi être utile.
urpmf est aussi votre ami
Les commandes que contient un paquet sont parfois imprécises. urpmf peut être utilisé de deux façons. Il peut lister le contenu des paquets et aussi trouver le paquet auquel se réfère en particulier un fichier.
L’utilisation de urpmf Permet de retrouver dans quel paquetage se situe un fichier précis.
| $ urpmf <package> | grep /usr/bin/ |
Cette liste répertorie tous les fichiers installés par le paquetage dans le répertoire /usr/bin/, où se trouvent les commandes utilisateur. Vous pouvez également utiliser /usr/sbin, bin ou sbin. urpmf effectue une recherche approximative des paquets, ce qui signifie que les résultats s’afficheront pour tous les paquets contenant votre terme de recherche. Par exemple, la recherche de wireshark renvoie également les résultats pour lib64wireshark-devel, wireshark-libvirt, wireshark-tools, alors soyez vigilant lorsque vous lisez les résultats.
Si vous avez besoin de trouver la provenance d’un fichier en particulier, dans ce cas précis pour le fichier urpmf application-wireshark-doc.png le paquet suivant est wireshark
| $ urpmf /chemin/vers/fichier |
RPM est également votre ami
Parfois vous souhaitez, savoir si un paquet est installé, et, rechercher une chaîne de caractères dans ces paquets.
rpm peut être utilisé dans ces circonstances.
- Le premier exemple indique l’absence du paquet.
- Le deuxième exemple montre si un paquet en particulier est installé.
- Le troisième exemple montre tous les paquets d’installés.
Rétrograder la version d’un paquet sans supprimer la moitié de votre bureau
Pendant le test, vous devez parfois revenir à la version précédente d’un paquet, si quelque chose ne va pas et vous devez vérifier si c’est une régression ou si cela engendre des problèmes ailleurs. Parfois les dépendances peuvent être un problème, vous pouvez par exemple vouloir supprimer quelque chose qui est indispensable pour la moitié de votre environnement de travail. Il vous demandera de supprimer la moitié de votre environnement de travail !
Pas de souci. Il y a un moyen de faire marche arrière.
| # urpmi --downgrade <package><target-version> |
Par exemple sur un système 64 bits si vous avez testé sudo-1.8.12-1 à partir du dépôt testing et que vous souhaitez revenir à la version lors de sa sortie, sudo-1.8.8-3, la commande devrait être :
| # urpmi --downgrade sudo-1.8.8-3.mga4.x86_64 |
Une alternative est de préciser le dépôt contenant la version à rétrograder :
| urpmi --downgrade --media "Core Release" sudo |
ou si le paquet a des dépendances dans un autre dépôt :
| urpmi --downgrade --search-media "Core Release" sudo |
Vous pouvez utiliser une autre méthode, plus sale : forcer la suppression d’un RPM donné indépendamment des autres RPM qui en dépendent. Cela laissera votre base de données RPM dans un état incohérent (ne redémarrez pas dans cet état) jusqu’à ce que vous réinstalliez le RPM dans la version souhaitée.
| # rpm -e --nodeps <package> |
Modules Perl
Les modules Perl sont typyquement notation chameau et sensible à la casse et la casse et nos modules perl packagés ressemblent à perl-FileMineInfo ou perl-DBD-SQLite il peut donc être difficile de deviner le nom du paquet du module perl requis.
Dans un script, les modules perl nécessaires sont généralement listés en haut de la liste et ressemblent à quelque chose comme :
| use IO::Socket use Net::Patricia |
Si vous pensez qu’il vous manque un module Perl et que vous voulez savoir de quoi il s’agit ou si vous savez que vous avez besoin de quelque chose comme Net::Patricia et que vous souhaitez savoir le paquet qu’il contient, vous pouvez utiliser l’une des deux commande ci-dessous :
| $ urpmf --provides --literal 'perl(Net::Patricia)' |
ou
| $ urpmq --whatprovides 'perl(Net::Patricia)' |
Une de ces commandes trouve le paquet nécessaire, dans ce cas perl-Net-Patricia. perl(Net::Patricia) est ce qu’on appelle un besoin virtuel ou une dépendance virtuelle, par opposition à une dépendance normale qui serait un nom de paquet.
Vous verrez parfois des résultats déroutants comme ci-dessous où il se répète apparemment, séparés par des |'s. Il s’agit en fait de lister les options disponibles qui satisfont les besoins virtuels. Dans ce cas, il liste deux options qu’il a trouvées plusieurs fois dans les référentiels. Il liste les éléments qu’il trouve dans les mises à jour ainsi que dans les versions et peut donc lister le même paquet un certain nombre de fois.
Gnome
Depuis Gnome 3.12, gnome ne crée plus de fichier /var/log/Xorg.0.log pour la journalisation X. L’information est maintenant stockée dans le journal. Vous pouvez utiliser journalctl pour récupérer les mêmes informations et les enregistrer dans un fichier qui peut être joint à un rapport de bogue.
| # journalctl _COMM=X > /home/<YourUsername>/journal-xorg.txt # chown <YourUsername> /home/<YourUsername>/journal-xorg.txt |
Évidemment, lorsque vous faites cela, vous devez remplacer <VotreNomUtilisateur> par votre nom d’utilisateur effectif.
Options du noyau
Les options du noyau peuvent être utilisées lors du démarrage de grub2 pour transmettre celles-ci au noyau lorsqu’il démarre. Cela peut être utile pour contourner les problèmes de GPU, d’ACPI, de PCI, etc. Il peut même être utilisé pour bannir certains pilotes ou forcer un point d’arrêt dans le processus de démarrage.
Voir la page des options du noyau pour plus d’informations.
Bibliothèques utilisées
lsof (list open file) peut être utilisé pour lister les bibliothèques partagées qui sont en cours d'utilisation par une application.
Par exemple, rechercher libpixman avec firefox :
