Пълно ръководство за докладване за грешки в Debian Linux

Докладването на грешки е един от многото начини да помогнете на Linux да расте. Всички дистрибуции на свободен софтуер, проектите имат различни системи, в които се събират, анализират, обозначават и фиксират бъгове в зависимост от броя на хората, които познават изходния код.

Тъй като обичам Debian, ще ви покажа как да подавате отчети за грешки в Debian.

Как да съобщаваме за грешки в Debian Linux

Инструментът goto в Debian за докладване на грешки е Reportbug . Иска ми се да знаех за това, когато започнах с докладване на грешки, бих избегнал доста киселини за себе си, както и за поддръжника.

Нека видим как можем да използваме Reportbug за отчитане на грешки в Debian Linux.

Стъпка 1. Инсталиране на Reportbug

Използвайте командата по-долу, за да инсталирате Reportbug:

sudo aptitude install reportbug

Стъпка 2. Reportbug: Първият цикъл

След като инсталирате Reportbug, при първото пускане трябва да го конфигурирате, така че да може да се използва за подаване на доклади за грешки.

Използвайте командата по-долу, за да я изпълните.

reportbug

И тогава куп заявки, както може да се види по-долу:

Бележки в Reportbug първа:

а. Тъй като използвам Debian от доста време, мога да превключвам между 2 и 3. За хора, които са изключително нови в отчитането на грешки, те могат да се придържат към [1], което е показано на новак и по подразбиране, просто натиснете Enter.

б. Между текстовия интерфейс и интерфейса gtk2 / 3 намирам интерфейса gtk2 / 3 за непривлекателен и също така вземам малко памет, затова избирам 1 през цялото време. Ако сте избрали gtk2 / 3 редактора, инструкциите по-долу са еднакви за вас, само че ще видите gtk-редактора, показващ едно и също нещо по малко по-красив начин.

° С. Частта, в която Reportbug иска достъп до мрежата, винаги я отказвам за практическа, както и за сигурност гледна точка. По-малко обяснение по причините, които правя, ще бъде споделено по-долу.

д. Накрая, когато попита за името, ако ви харесва съществуващото име (от променливата [email protected]), натиснете Enter, в случай, че искате да бъде нещо друго, дайте името, с което искате да се появи.

Стъпка 3. Обработката на Gmail

Първият път, когато Reportbug ще се стартира, ще поиска настройка на пощата:

Първият въпрос е да ви попита дали имате някакъв софтуер, който ще му позволи автоматично да изпраща имейли.

Ако сте настроили настолен клиент за електронна поща като Evolution или Thunderbird, изберете yes. Иначе, не.

След като файлът с предпочитанията по подразбиране е написан, той се записва в /home/shirish/.reportbugrc. Можете да промените конфигурацията по-късно, като редактирате този файл.

На конзолата можете да използвате CTRL + C, за да излезете от Reportbug във всеки един момент.

Стъпка 5. Определете име на пакет от приложения от двоичен файл

Нека да вземем примера на Aiselriot. Това е една от игрите на GTK Card, които майка ми играе много. Сега, ако има проблем с играта как да разбера под какъв пакет трябва да подаде доклад за грешка?

Така че първото нещо, което правя, когато се опитвам да отстраня GUI приложение, е да си взема иконата и да я поставя на панела и да виждам неговите свойства точно както се показва тук -

Сега знам, че името на приложението. не е Aiselriot, но sol и пътя, където се поставя приложението е в /usr/games/sol .

Сега нека опитаме да намерим какъв пакет се нарича -

dpkg -S /usr/games/sol

Резултатът е:

aisleriot: / usr / games / sol

Щастливи сме, че пакетът се нарича още aiselriot, но това не се случва през цялото време.

Продължавайки, нека сега да докладваме за нашия първи доклад за грешки. Тъй като аз използвам Debian тестване / стречинг / скоро ще бъде стабилен в рамките на няколко месеца, ще се поставя бъг-доклад през там.

Стъпка 6. Използване на Reportbug за създаване на доклад за грешка

Сега имаме нужда от пакет, който има проблем / грешка, който трябва да докладваме на общността на Debian.

Имам пакет piuparts, който показва симптоми на проблем, за който се обърнах към Reportbug като показан в същността:

Нека сега обясня как работят нещата. Използвам инструмент, наречен подходящ (който е инструмент за проверка на Debian пакет) при инсталирането на пакети. Ще говоря за адекватно подробно в някакъв бъдещ блог пост.

Това, което Reportbug прави, е да получи и анализира цялата информация, която има за пакета, така че да знае дали да продължи напред или не.

Сега инструментът работи постоянно във фонов режим. Една от основните му задачи се случва в самия край на инсталацията на пакета, например за piuparts, която споделя / ми показа това -

adequate found packaging bugs

-----------------------------

piuparts: остарял-conffile / etc / piuparts / scripts / post_setup_experimental

което ми каза, че пакетът piuparts имаше остаряла conffile. Conffile означава Configuration file.

Така че първата команда, която правя, когато открия грешка, за която си струва да докладвам, е, че правя това -

reportbug piuparts --severity=normal

Дава / разказва за пакета, който има проблем, в случая piuparts.

Поставянето на строгост на всяка грешка е трудна работа. Освен ако нямам доста силни чувства по отношение на пакета и знам без съмнение, че бъгът е наистина тежък, аз не вдигам тежестта. Това е моята лична етика, също малко по-малко работа за поддръжник.

Това се казва, че повечето поддръжници ще гледат на бъг, въпреки каквато и да е тежест. Имам отговорници, които ми отговарят бързо, дори когато съм подал бъгове от списъка с желания и имам поддръжници, които не се връщат. MIA (Missing-In-Action) дори след подаване на тежки грешки. Подаването и провеждането на здравословен разговор с поддръжника е както техническа, така и социална дейност.

След като зададете въпроса, reportbug пита / дава различни опции, ако се прилага едно от условията. Можете да използвате всички, ако смятате, че вашият бъг е засегнат или засяга едно от горепосочените неща в списъка. Например, ако ще споделите кръпка, за да решите проблема, ще изберете 6 или един от другите. Ако никой от тях не е необходим, просто въведете и продължете напред.

След като го направите, ще отнеме няколко минути и ще получим нещо подобно на споделеното съдържание:

Сега това е това, което дава идея на поддръжника на състоянието на вашата система. Както всички знаете, почти всички GNU / Linux дистрибуции и пакетите в тях се основават на сложен набор от взаимоотношения с други пакети. Поддръжникът трябва да знае каква версия на пакета сте използвали, кои други пакети има, каква версия са те, освен че знаят, че целостта на пакета не е била подправена по никакъв начин.

Сега трябва да попълните банките -

Обикновено премахвам / изтривам изрежете следното, ако сте нов потребител, можете просто да отговорите на въпросите по-долу и вашият доклад за грешка ще бъде готов.

Стъпка 7. Окончателните промени, направени за изразходване на доклада

И на негово място, поставям детайлите като споделени тук:

Още информация. Сега - Тези два маркера сигнализират / казват на поддръжниците няколко неща -

Потребител: [email protected]

Първият маркер сигнализира, че повдигнатият бъг е част от усилията на debian-qa.

Usertags: obsolete-conffile adequate

Вторият таг показва инструмента, който сме използвали, и един от най-често срещаните проблеми, при които е дошъл - в този случай остарял-conffile.

Има няколко общи и необичайни случаи, в които адекватно се разглеждат. Както споделите преди, ще се нуждаете от друг блог, за да го споделите подробно.

Другото, което казвам / споделям, е, че той / тя трябва да търси в debhelper (инструментариум за debian / rules) и да търси в него конкретни битове.

Съвет - Пол Уайз, по-известен като паби в общността на Дебиан. Той е плодовит принос към Debian. Както можете да видите от неговата уики страница и второстепенните приложения. Той винаги има безкраен списък от приложения, пакети, които биха били интересни за пакетиране заедно с неща, които биха могли да бъдат / трябва да бъдат подобрени. Не знам дали е направил някакво наставничество или не, виждам в него признаци на добър и шантав наставник. Понякога питам, понякога крадат идеите му, за да помагам в Debian QA :)

Сега, когато докладът за грешки е завършен, трябва да го изпратя чрез gmail.com. Ако сте активирали MTA (агент за прехвърляне на поща) и нямате gmail.com, можете просто да го изпратите и това ще бъде направено. Ако, от друга страна, не сте активирали MTA (като мен) и обичате да правите нещата сами, влезте в профила си в gmail, натиснете „Компилиране“ и след това -

Стъпка 8. Последната стъпка

To - [email protected]

Предмет - пиапорти: адекватни съобщения за остарели конфили за пиапорти

Тялото на вашата поща трябва да започва с пакет

нещо като това -

Може би сте забелязали някои етикети, те са само за да ми помогнат да бъда малко организиран, тъй като след като сте докладвали за някои грешки, може да стане хаотично да знаете какво се случва. Етикетите и филтрите на Gmail правят нещата много по-слаби с количеството поща, която получавам.

В този момент не забравяйте да проверите отново пощата, преди да кликнете върху бутона за изпращане на поща. Обикновено кликвам върху „Запазване на чернова“, го преглеждам веднъж или два пъти преди да го изпратя.

Ако сте доволни, кликнете върху изпратете и вашият доклад за грешка ще бъде изпратен на Debian BTS.

Стъпка 9. Получаване на потвърждение от Debian BTS сървър, че бъгът е достигнал до тях.

Обикновено в рамките на минути получавам кратка поща за потвърждение от Debian BTS, като в общата информация, която се споделя

Погледнете маркираното време, само на 3 минути от изпращането на пощата. Изпратих бъг по пощата на 05:03 и имам автоматичен отговор, казвайки, че всичко се оправи на 05:06.

Това, което търся в пощата за потвърждение, е номерът на грешката, тъй като това е начинът да разбера как вървят нещата с грешката.

# 854317

Цикъл за отчитане на грешки в публикацията.

Случайно, както може да се види, поддръжникът на пакета някак си беше по времето, когато подадох грешката. Знам значението на piuparts в екосистемата на debian, но не мислех, че Andreas ще действа толкова бързо, така че сега вероятно следващото издание на точка или дори съобщение за бъгове ще има решение. Както може да се види обаче, Андреас изглежда като зает пчел, виждайки броя пакети, които поддържа / поддържа, освен да качва не-поддържащи качвания (NMU) и качвания на QA.

Надявам се, че съм дал достатъчно прозрение, за да знаете какво да правя, когато и когато нещата се объркат.

Съвет - В днешно време обикновено следвам няколко правила, преди да подам грешка. Първо проверете bts за съществуващия списък с бъгове, например за страницата за бъгове piuparts (както споделя и Саймън Татъм по-горе). Ако бъгът не е включен там, по-често, отколкото не, пакетът не е твърде много зависимости, и знам, че няма никакви конфигурационни файлове, които може да се наложи да пресъздам, след това обикновено изчиствам пакета и инсталирам пакета отново. Ако адекватно все още открива грешка, обикновено го докладвам. Аз не правя това, обаче, за остарели conffiles, тъй като те обикновено се случват, когато сте надграждане от версия x.1 до x.2 или нещо подобно.

Използвайки такива прости съвети, спестявам време и енергия за себе си, както и за поддръжника на пакет.

Първо може да отнеме някой път, след известно време цялото нещо може да отнеме 10-15 минути или дори по-малко, в зависимост от пакета, в който е открит бъг, самото бъг, репликацията на грешката и т.н.

Това е, за да направите доклад за грешка в Debian с помощта на Reportbug.

Надяваме се, че сте получили някаква представа за стъпките за намиране на грешки и за тяхното докладване. Моля, публикувайте всички въпроси, които имате в коментарите по-долу и ще се опитам да отговоря / споделям каквото и малко да знам.

Препоръчано

digiKam 5.0 Издаден! Инсталирайте го в Ubuntu Linux
2019
Mycroft Mark II: Отговорът с отворен код на Amazon Echo и Google Home, който не ви шпионира
2019
13 неща, които трябва да направите след инсталирането на Ubuntu 17.04
2019