 |
Other languages Deutsch; English; français; Nederlands ; |
| In het kort: Deze pagina is bedoeld om nieuwe leden wat richtlijnen te geven. Het kan lastig zijn om te weten waar u moet beginnen, vooral als u nog nooit eerder een pakket bent tegengekomen. Dit is een plek waar we onze tips en trucs kunnen delen en het voor nieuwe leden (en oude) makkelijker kunnen maken om QA-tests voor Mageia uit te voeren. Als u iets kunt verbeteren, doe dat dan alstublieft. |
Contents
De wiki
De eerste plek om te kijken is hier op de wiki. U kunt links naar testprocedures vinden via de QA Team portal. Eigenlijk zouden we deze vaker moeten voltooien, het zou een waardevolle bron kunnen worden. Er zijn er tot nu toe maar een paar toegevoegd, maar als u dit leest en op zoek bent naar een procedure, overweeg dan om deze daar toe te voegen als u er een vindt. Iedereen met een Mageia-identiteit kan de wiki bewerken, dat betekent iedereen die bijvoorbeeld kan inloggen op de forums of bugzilla. Een Mageia-identiteit kan worden gebruikt om in te loggen op elke Mageia-website.
Bugzilla - Man pages - Google
Een goede plek om te beginnen als u op zoek bent naar een manier om een pakket te testen, is om bugzilla te doorzoeken om te zien hoe het eerder werd gedaan. Natuurlijk zal niet alles daar zijn, maar er zijn enkele pakketten die relatief vaak updates ontvangen en terugkijken naar eerdere updates geeft meestal een goed idee hoe u deze update ook kunt testen.
U kunt zoeken naar gesloten bugs met betrekking tot het pakket dat u wilt testen. Het is het gemakkelijkst om dat te doen door op de link Zoeken op bugzilla te klikken in plaats van het gewoon in het zoekvak in te voeren. Met behulp van Eenvoudig zoeken selecteert u gewoon gesloten als de status. U kunt ook Mageia selecteren voor Product om de zoekopdracht te verfijnen.
Vergeet ook de manpagina en Google niet.
$ man <package>
Soms zult u merken dat u, als er geen manpagina is. De opdracht die u wilt testen kunt u dan gebruiken met --help aan het einde. Bijvoorbeeld,
$ man --help
URPM-wat?
Urpm-gereedschappen zijn erg krachtig. Er zijn veel opties beschikbaar, maar slechts een kleine subset waar we ons zorgen over hoeven te maken in QA. U kunt hier veel informatie vinden over verschillende gereedschappen. Het is de moeite waard om te lezen. U kunt ook de manpagina's voor elk van hen bekijken
bijv.
$ man urpmi
Handige aliassen
Hier zijn enkele aliassen die u wellicht handig vindt bij het uitvoeren van QA-taken.
Deze aliassen moeten in het bestand /root/.bashrc worden geplaatst
Nadat u ze hebt toegevoegd, moet u uitloggen en opnieuw inloggen.
Als u er nog meer kent waarvan u denkt dat ze nuttig kunnen zijn voor anderen, voeg ze dan toe.
# QA aliases for enabling, disabling and updating core, nonfree and tainted updates testing medias. alias ecupdt='echo -e "Enabling Core Updates Testing\n" && urpmi.update --no-ignore "Core Updates Testing"' alias dcupdt='echo -e "Disabling Core Updates Testing\n" && urpmi.update --ignore "Core Updates Testing"' alias cupdt='echo -e "Updating Core Updates Testing\n" && urpmi.update "Core Updates Testing"' alias enfupdt='echo -e "Enabling Nonfree Updates Testing\n" && urpmi.update --no-ignore "Nonfree Updates Testing"' alias dnfupdt='echo -e "Disabling Nonfree Updates Testing\n" && urpmi.update --ignore "Nonfree Updates Testing"' alias nfupdt='echo -e "Updating Nonfree Updates Testing\n" && urpmi.update "Nonfree Updates Testing"' alias etupdt='echo -e "Enabling Tainted Updates Testing\n" && urpmi.update --no-ignore "Tainted Updates Testing"' alias dtupdt='echo -e "Disabling Tainted Updates Testing\n" && urpmi.update --ignore "Tainted Updates Testing"' alias tupdt='echo -e "Updating Tainted Updates Testing\n" && urpmi.update "Tainted Updates Testing"'
Urpmq is uw vriend
$ urpmq -i <package>
Urpmq vereist geen root-rechten. Het commando kan worden uitgevoerd als een normale gebruiker, vandaar het $ teken, dat u zult zien als uw prompt in een console, wanneer u bent ingelogd als een normale gebruiker. Dit is een algemene notatie en u zult het overal in de wiki zien. Een opdracht die wordt uitgevoerd als root wordt voorafgegaan door een # teken, wat de root prompt is.
Deze opdracht toont nuttige informatie over een pakket, inclusief een beschrijving, bron-rpm en architectuur (i586, x86_64 of noarch), en de groep, wat u misschien een idee geeft waarvoor het wordt gebruikt.
$ urpmq –whatrequires <package>
Als u –whatrequires gebruikt, krijgt u een lijst met pakketten die het pakket vereisen waarnaar u zoekt. Dit kan handig zijn als er geen voor de hand liggende manier is om het pakket dat wordt bijgewerkt rechtstreeks te testen. U kunt dan een pakket gebruiken dat dit pakket gebruikt om het te testen. Dit is vaak handig bij het testen van lib's.
$ urpmq –whatrequires-recursive <package>
Deze retourneert een lijst met pakketten die het pakket nodig hebben waarnaar u zocht en ook alle pakketten die ze ook nodig hebben. De lijst kan behoorlijk lang zijn! Het kan echter nuttig zijn.
urpmf is ook uw vriend
Het is niet altijd precies duidelijk welke opdrachten een pakket bevat. urpmf kan op twee manieren worden gebruikt. Het kan de inhoud van pakketten weergeven, maar ook het pakket vinden waartoe een bepaald bestand behoort.
Gebruik urpmf om te zoeken naar opdrachten die door een pakket zijn geïnstalleerd.
$ urpmf <pakket> | grep /usr/bin/
Hiermee worden alle bestanden weergegeven die door het pakket zijn geïnstalleerd in /usr/bin, waar normale gebruikersopdrachten naartoe gaan. U kunt dit vervangen door /usr/sbin of gewoon bin of sbin. urpmf voert een fuzzy zoekopdracht uit voor pakketten, wat betekent dat het resultaten zal tonen voor alles wat uw zoekterm bevat. bijvoorbeeld Zoeken naar wireshark, geeft ook resultaten voor lib64wireshark-devel, wireshark-libvirt, wireshark-tools, dus let op wanneer u de resultaten leest.
Als u de bron van een specifiek bestand moet vinden, in dit geval voor het bestand urpmf application-wireshark-doc.png, is het volgende pakket wireshark.
$ urpmf /pad/naar/bestand
RPM is ook uw vriend
Er zijn momenten waarop u wilt weten of u een pakket hebt geïnstalleerd of niet, of wilt weten welke pakketten u hebt geïnstalleerd en ze wilt doorzoeken op een tekenreeks.
Rpm kan in deze omstandigheden worden gebruikt. De twee onderstaande voorbeelden tonen eerst hoe u kunt zien of een bepaald pakket is geïnstalleerd; het tweede voorbeeld laat zien hoe u al uw geïnstalleerde pakketten kunt doorzoeken.
$ rpm -q <pakket> $ rpm -qa | grep <string>
Een pakket downgraden zonder de helft van u bureaublad te verwijderen
Tijdens het testen moet u soms terug naar de bestaande versie van een pakket, als er iets mis is en u moet controleren of het bijvoorbeeld een regressie is of dat het ergens anders problemen veroorzaakt. Soms kunnen afhankelijkheden een probleem zijn, bijvoorbeeld als u iets wilt verwijderen dat nodig is voor de helft van u bureaublad. Het zal vragen om de helft van u bureaublad te verwijderen!
Wees niet bang. Er is een manier om het te downgraden.
# urpmi --downgrade <package><target-version>
Als u bijvoorbeeld op een 64-bits systeem sudo-1.8.12-1 hebt getest vanuit de testing repo en wilt terugkeren naar de versie in release, sudo-1.8.8-3, dan zou de opdracht zijn:
# urpmi --downgrade sudo-1.8.8-3.mga4.x86_64
Een alternatief is om de repo te specificeren die de versie bevat waarnaar moet worden gedowngraded:
urpmi --downgrade --media "Core Release" sudo
of als het pakket afhankelijkheden heeft in een andere repo:
urpmi --downgrade --search-media "Core Release" sudo
U kunt een andere, viezere, manier gebruiken: forceer verwijdering van een bepaalde RPM, ongeacht andere RPM's die ervan afhankelijk zijn. Dit laat uw RPM-database in een inconsistente staat achter (start niet opnieuw op in die staat) totdat u de RPM opnieuw installeert in de gewenste versie.
# rpm -e --nodeps <package>
Downgrade alles vanuit testing repositories
Om uw systeem zodanig te synchroniseren, dat het alleen pakketten en versies bevat van de release en update repositories.
- Lees over this usage of DNF.
dnf offline-distrosync download --disablerepo=\*testing\* --allowerasing
Perl-modules
Perl-modules zijn doorgaans CamelCase en hoofdlettergevoelig en onze verpakte perl-modules zien er ongeveer uit als perl-FileMineInfo of perl-DBD-SQLite, dus het kan moeilijk zijn om de pakketnaam te raden op basis van de perl-modulerequire.
In een script worden benodigde perl-modules meestal bovenaan weergegeven en zien er ongeveer zo uit:
use IO::Socket use Net::Patricia
Als u merkt dat u een perl-module mist en u wilt weten wat het is of als u weet dat u iets als Net::Patricia nodig hebt en wilt weten welk pakket dat biedt, kunt u een van de onderstaande opdrachten gebruiken..
$ urpmf --provides --literal 'perl(Net::Patricia)' perl-Net-Patricia:perl(Net::Patricia) of $ urpmq --whatprovides 'perl(Net::Patricia)' perl-Net-Patricia
Een van deze twee zou het daadwerkelijk benodigde pakket vinden, in dit geval perl-Net-Patricia. De perl(Net::Patricia) is wat bekend staat als een virtuele requirement of virtuele afhankelijkheid, in tegenstelling tot een normale require die een pakketnaam zou zijn.
Soms ziet u verwarrende uitvoer zoals hieronder, waar het zichzelf schijnbaar herhaalt, gescheiden door |'s. Het geeft in feite beschikbare opties weer die voldoen aan de virtuele require. In dit geval geeft het twee opties weer die het meerdere keren in de repositories heeft gevonden. Het commando geeft onderwerpen weer die het vindt in updates en release en kan dus hetzelfde pakket meerdere keren weergeven.
$ urpmq --whatprovides 'perl(ExtUtils::Packlist)' perl-ExtUtils-Install|perl-ExtUtils-Install|perl|perl|perl
Gnome
Vanaf Gnome 3.12 maakt gnome geen /var/log/Xorg.0.log-bestand meer voor X-logging. De informatie wordt nu opgeslagen in het journaal. U kunt journalctl gebruiken om dezelfde informatie te herstellen en deze op te slaan in een bestand dat kan worden toegevoegd aan een bugrapport.
# journalctl _COMM=X > /home/<YourUsername>/journal-xorg.txt # chown <YourUsername> /home/<YourUsername>/journal-xorg.txt
Uiteraard moet u, wanneer u dit doet, <UwGebruikersnaam> vervangen door uw werkelijke gebruikersnaam.
Kernelopties
Kernelopties kunnen worden gebruikt in de grub/grub2-bootfase om opties door te geven aan de kernel wanneer deze opstart. Dit kan handig zijn om GPU-problemen, ACPI-problemen en PCI-problemen te omzeilen. Het kan zelfs worden gebruikt om bepaalde drivers op een zwarte lijst te zetten of een breekpunt in het opstartproces te forceren.
Zie de pagina kernel options voor meer informatie.
Gebruikte bibliotheken
lsof (list open files) kan worden gebruikt om de gedeelde bibliotheken te vermelden die door een applicatie worden gebruikt die momenteel wordt uitgevoerd.
Bijvoorbeeld, zoeken naar libpixman met firefox:
# lsof | grep firefox | grep libpixman firefox 8801 user mem REG 8,2 707048 137291 /usr/lib64/libpixman-1.so.0.32.8 firefox 8801 8841 user mem REG 8,2 707048 137291 /usr/lib64/libpixman-1.so.0.32.8
