Komplet guide til fejlrapportering i Debian Linux

Rapportering af fejl er en af ​​de mange måder, du kan hjælp linux vokse. Alle gratis softwarefordelinger, projekter har forskellige systemer, hvor fejl opsamles, analyseres, mærkes og fastgøres afhængigt af antal personer, der kender kildekoden.

Siden Jeg elsker Debian, Jeg viser dig, hvordan du sender fejlrapporter i Debian.

Sådan rapporteres fejl i Debian Linux

Goto-værktøjet i Debian for at rapportere fejl er reportbug. Jeg ville ønske jeg havde vidst det, da jeg begyndte med fejlrapportering, ville have undgået en smule halsbrand for mig selv såvel som vedligeholderen.

Lad os se, hvordan kan vi bruge Reportbug til fejlrapportering i Debian Linux.

Trin 1. Reportbug Installation

Brug kommandoen nedenfor til at installere Reportbug:

sudo aptitude install reportbug

Trin 2. Reportbug: Første runde

Når du først har installeret Reportbug, skal du i første omgang konfigurere det, så det kan bruges til at indsende fejlrapporter.

Brug kommandoen nedenfor til at køre den.

reportbug

Og så en masse spørgsmål som kan ses som nedenfor:

Se koden på Resumé.

Noter om Reportbug første runde:

en. Da jeg har brugt Debian i nogen tid, kan jeg skifte mellem 2 og 3. For folk, der er meget nye til fejlrapportering, kunne de holde sig til [1], som vises novice og standard, tryk blot Enter.

b. Mellem tekstbrugergrænsefladen og gtk2 / 3-grænsefladen finder jeg gtk2 / 3-grænsefladen utilløsende og også tager lidt hukommelse, derfor vælger jeg 1 hele tiden. Hvis du vælger gtk2 / 3 editoren, er instruktionerne nedenfor stadig de samme for dig. Kun GTK-editoren viser det samme på en lidt smukkere måde.

c. Den del, hvor Reportbug beder om netadgang, benægter jeg altid det til praktisk, såvel som sikkerhedssynspunkt. Lidt mere forklaring på grundene til, at jeg gør det, vil blive delt nedenfor.

d. Endelig, når den beder om navnet, hvis du kan lide det eksisterende navn (tager fra [Email protected] variabel) tryk på Enter, hvis du vil have, at det skal være noget andet, angiv det navn, som du vil have det vist på.

Trin 3. Håndtering af Gmail-quirks

Første gang Reportbug ville blive kørt, ville det bede om opsætning af mail:

Se koden på Resumé.

Det første spørgsmål spørger, om du har nogle software, der gør det muligt for dig at sende e-mails automatisk.

Hvis du har konfigureret en desktop e-mail-klient som Evolution eller Thunderbird, skal du vælge ja. Ellers, gå til nej.

Når standardindstillingsfilen er skrevet, gemmes den på /home/shirish/.reportbugrc. Du kan ændre konfigurationen senere ved at redigere denne fil.

På konsollen kan du bruge CTRL + C for at afslutte Reportbug til enhver tid.

Trin 5. Beregning af et programpakke navn fra en binær

Lad mig tage eksemplet med Aiselriot. Det er et af GTK Card-spil, som min mor spiller meget. Nu, hvis der er et problem med spillet, hvordan finder jeg ud af, under hvilken pakke skal jeg indsende en fejlrapport?

Så det første, jeg gør, når jeg forsøger at fejle en GUI-applikation, er at tage sit ikon og sætte det på panelet og se dens egenskaber ligesom jeg viser her -

Nu ved jeg, at navnet på appen. er ikke Aiselriot, men sol og stien, hvor ansøgningen er sat op er på / Usr / spil / sol.

Lad os nu prøve at finde ud af hvad pakken hedder -

dpkg -S / usr / games / sol

Udgangen er:

aisleriot: / usr / games / sol

Vi er heldige at pakken også kaldes aiselriot, men det sker ikke hele tiden.

Vi fortsætter med at rapportere vores første fejlrapport. Da jeg bruger Debian test / strække / snart at være stabil om nogle få måneder, vil der blive lavet en fejlrapport derovre.

Trin 6. Brug Reportbug til at lave en fejlrapport

Nu har vi brug for en pakke, der har et problem / fejl, som vi skal rapportere til Debian-fællesskabet.

Jeg har en pakke piuparts, der viste symptomer på et problem, som jeg vendte mig til Reportbug som vist i kernen:

Se koden på Resumé.

Lad mig nu forklare, hvordan tingene virker. Jeg bruger et kaldt værktøj passende (som er et Debian-pakke-kontrolværktøj), når du installerer pakker. Jeg vil tale om passende i detaljer i nogle fremtidige blogindlæg.

Hvad Reportbug gør, er at få og analysere alle de oplysninger, den har om pakken, så det ved, om man skal fortsætte fremad eller ej.

Nu er værktøjet tilstrækkeligt kører i baggrunden hele tiden. En af sine vigtigste job forekommer lige i slutningen af ​​en pakkeinstallation, for fx for piuparts deler den / viste mig det her -

passende fundet emballage bugs -----------------------------

piuparts: forældede-konffile / etc / piuparts / scripts / post_setup_experimental

som fortalte mig, at piuparts-pakken havde en forældet konffil. Konfile står for konfigurationsfilen.

Så den første kommando, jeg gør, når jeg finder en fejl, der er værd at rapportere, gør jeg det her -

reportbug piuparts --severity = normal

Giver / fortæller om pakken, der har problemet, i dette tilfælde piuparts.

At gøre sværhedsgraden til enhver fejl er en vanskelig forretning. Medmindre jeg har temmelig stærke følelser om en pakke og ved uden tvivl, at fejlen er alvorlig, øger jeg ikke sværhedsgraden. Dette er min egen personlige etik, også lidt mindre arbejde for en vedligeholder.

Når det er sagt, vil de fleste vedligeholdere se på en fejl, uanset hvor alvorlig du giver. Jeg har haft vedligeholdere reagere mig hurtigt på mig selv, når jeg har indgivet ønskeseddel fejl og jeg har vedligeholdere ikke komme tilbage. MIA (manglende handling) selv efter indgivelse af alvorlige fejl. Arkivering og en sund samtale med underviseren er en teknisk såvel som en social aktivitet.

Efter spørgsmålet spørger reportbug / giver forskellige muligheder, hvis en af ​​betingelserne gælder. Du kan bruge nogen, hvis du mener, at din fejl er påvirket eller påvirker en af ​​ovenstående ting på listen. Hvis du f.eks. Deler en patch for at løse problemet, vælger du 6 eller en af ​​de andre. Hvis ingen af ​​dem er nødvendige, skal du blot indtaste og gå videre.

Når ovenstående er gjort, tager det et par øjeblikke, og vi får noget, der ligner dette delte kerne:

Se koden på Resumé.

Nu hvad det her er, giver det en ide til opretholderen af ​​tilstanden i dit system. Som du ved alle, er næsten alle GNU / Linux-distributioner og pakkerne deri baseret på et komplekst sæt af relationer med andre pakker. Underleverandøren skal vide, hvilken version af pakken du brugte, hvilke andre pakker var der, hvilken version var de hos, bortset fra at vide, at pakkenes integritet ikke er blevet manipuleret på nogen måde.

Nu skal du udfylde bankerne -

Jeg fjerner / sletter normalt følgende: Hvis du er ny bruger, kan du bare svare på nedenstående spørgsmål, og din fejlrapport vil være klar.

Trin 7. De endelige ændringer foretaget for at bruge rapporten

Og i stedet sætter jeg detaljerne som delte lige her:

Se koden på Resumé.

Noget mere info. nu - disse to tags signal / fortælle de underholdende få ting -

User: [email protected]

Det første mærke er at signalere, at buggen bliver hævet, er en del af debian-qa-indsatsen.

Usertags: Forældet konfilt er tilstrækkeligt

Det andet mærke fortæller det værktøj, vi har brugt, og et af de fælles problemer, hvorunder det er kommet - i dette tilfælde forældet-konffil.

Der er få almindelige og usædvanlige brugssager, der ser tilstrækkeligt ud. Som delt før, skal du bruge et andet blogindlæg til at dele om det i detaljer.

Den anden ting jeg fortæller / deler vedligeholderen er, at han / hun skal undersøge debhelper (et værktøj til debian / regler) og at kigge efter specifikke bits deri.

Tip - Paul Wise, bedre kendt som pabs i Debians samfund. Han er en stor bidragyder til Debian. Som du kan se fra hans wiki side og de sekundære apps. Han har altid en uendelig liste over applikationer, pakker, der ville være interessante at pakke alongwith ting, der kunne / skal forbedres. Jeg kan ikke, hvis han har gjort nogen mentorskab eller ej, se tegn på en god og dum mentor i ham. Jeg spørger nogle gange, stjæler nogle gange hans ideer til at hjælpe i Debian QA ????

Nu, at fejlrapporten er færdig, skal jeg sende den via gmail.com. Hvis du har aktiveret MTA (Mail Transfer Agent) og ikke har en gmail.com, kan du bare sende og det vil blive gjort. Hvis du på den anden side ikke har aktiveret MTA (som mig) og gerne vil gøre ting selv, log på din gmail-konto, tryk komponere og derefter -

Trin 8. Det sidste trin

To - [email protected]
Subject - piuparts: adequate reports obsolete conffile for piuparts

Kroppen i din mail skal starte med pakken

noget som dette -

Du har muligvis bemærket nogle etiketter, de er bare for at hjælpe mig med at være noget organiseret, efter at du har rapporteret nogle fejl, kan det blive kaotisk at vide, hvad der sker. Gmail's etiketter og filtre gør tingene lidt hygiejne med mængden af ​​mail, jeg modtager.

På det tidspunkt skal du sørge for at tjekke mailen en gang mere, før du klikker på send mail-knappen. Jeg plejer at klikke på gemt udkast, gennemgå det en eller to gange, før du sender det over.

Hvis du er tilfreds, klik send og din fejlrapport sendes til Debian BTS.

Trin 9. Få bekræftelse fra Debian BTS-serveren, der siger, at fejlen har nået dem.

Normalt, inden for få minutter får jeg en kort bekræftelsespost fra Debian BTS, som i kernen delt

Se på det angivne tidsstempel, kun 3 minutter bortset fra, hvornår mailen blev sendt. Jeg sendte fejlmeddelelsen på 05: 03 og fik det automatiske svar, der sagde, at alt gik fint på 05: 06 selv.

Hvad jeg kigger efter i kvitteringsposten er fejlnummeret, da det er sådan, hvordan jeg kommer til at vide, hvordan tingene går med fejlen.

#854317

Post fejlrapporteringscyklus.

Til syvende og sidst, som det kan ses, var pakkevedligeholderen en eller anden måde omkring det tidspunkt, hvor jeg indgav fejlen. Jeg kender vigtigheden af ​​piuparts i debian økosystemet, men jeg tænkte ikke Andreas vil handle så hurtigt, så nu vil sandsynligvis den næste punktudgivelse eller endda bugfix-frigivelse få løsningen. Som det kan ses, synes Andreas at være travlt med at se antallet af pakker, som han opretholder / vedligeholder, udover at uploade ikke-vedligeholdelses uploads (NMU) og QA uploads.

Jeg håber jeg har givet nok indsigt, så du ved hvad du skal gøre, når og når tingene går galt.

Tip - I dag følger jeg normalt nogle regler inden du sender en fejl. Kontroller først bt. For eksisterende liste over bugs, for eksempel piuparts bugs side (som også delt af Simon Tatham ovenfor). Hvis fejlen ikke er opført der, oftere end ikke, har pakken ikke for mange afhængigheder, og jeg ved, at der ikke er nogen konfigurationsfiler, som jeg muligvis skal genskabe, og jeg plejer at rense pakken og installere pakken på ny. Hvis der stadig findes en fejl, rapporterer jeg det normalt. Jeg gør det ikke for forældede konffiler, som de normalt sker, når du opgraderer fra version x.1 til x.2 eller noget lignende.

Ved hjælp af sådanne enkle tips sparer jeg tid og energi for mig selv såvel som vedligeholderen af ​​en pakke.

I starten kan det tage et stykke tid, efterhånden kan det hele tage 10-15 minutter eller endnu mindre, afhængigt af pakken, hvor fejlen er fundet, selve fejlen, replikering af fejlen osv.

Det handler om at lave en fejlrapport i Debian ved hjælp af Reportbug.

Forhåbentlig har du fået en ide om, hvordan man finder fejl og rapporterer dem. Venligst skriv eventuelle spørgsmål, du har i kommentarerne nedenfor, og jeg vil prøve mit bedste for at svare / dele, uanset hvad jeg ved.

Kilde

Giv en kommentar

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.