Guia Completo para Relatar Erros no Debian Linux

Relatar bugs é uma das muitas maneiras de ajudar o Linux a crescer. Todas as distribuições de software livre, projetos têm sistemas diferentes nos quais bugs são coletados, analisados, rotulados e corrigidos dependendo do número de pessoas que conhecem o código-fonte.

Como eu amo o Debian, mostrarei como enviar relatórios de bugs no Debian.

Como relatar erros no Debian Linux

A ferramenta goto no Debian para relatar bugs é o Reportbug . Eu gostaria de ter sabido sobre isso quando comecei a reportar bugs, teria evitado um pouco de azia tanto para mim quanto para o mantenedor.

Vamos ver como podemos usar o Reportbug para relatar erros no Debian Linux.

Etapa 1. Instalação Reportbug

Use o comando abaixo para instalar o Reportbug:

sudo aptitude install reportbug

Etapa 2. Reportbug: a primeira execução

Depois de ter instalado o Reportbug, na primeira execução, você precisa configurá-lo para que ele possa ser usado para enviar relatórios de bugs.

Use o comando abaixo para executá-lo.

reportbug

E, em seguida, um monte de consultas, como pode ser visto abaixo:

Notas sobre a primeira execução do Reportbug:

uma. Como venho usando o Debian há algum tempo, posso alternar entre 2 e 3. Para pessoas que são extremamente novas no relato de bugs, elas podem manter o [1] que é mostrado como novato e o padrão, apenas pressione Enter.

b. Entre o texto UI e a interface gtk2 / 3, acho a interface gtk2 / 3 pouco atraente e também tendo um pouco de memória, por isso escolho 1 o tempo todo. Se você escolheu o editor gtk2 / 3, as instruções abaixo ainda são as mesmas para você, somente você verá o editor gtk mostrando a mesma coisa de uma maneira um pouco mais bonita.

c. A parte em que o Reportbug solicita o acesso à rede, eu sempre o nego por um ponto de vista prático e de segurança. Um pouco mais de explicação pelas razões que eu faço seria compartilhada abaixo.

d. Por fim, quando ele pede o nome, se você gosta do nome existente (toma da variável [email protected]) pressione Enter, caso você queira que seja outra coisa, dê o nome pelo qual você quer que apareça.

Etapa 3. Lidando com as peculiaridades do Gmail

A primeira vez que o Reportbug seria executado, ele solicitaria a configuração de email:

A primeira pergunta é se você tem algum software que lhe permitirá enviar e-mails automaticamente.

Se você configurou um cliente de e-mail de área de trabalho, como Evolution ou Thunderbird, escolha sim. Mais, vá em frente.

Depois que o arquivo de preferências padrão é gravado, ele é salvo em /home/shirish/.reportbugrc. Você pode alterar a configuração posteriormente, editando este arquivo.

No console, você pode usar CTRL + C para sair do Reportbug a qualquer momento.

Etapa 5. Descobrir um nome de pacote de aplicativo de um binário

Deixe-me tomar o exemplo de Aiselriot. É um dos jogos de cartas GTK que minha mãe joga muito. Agora, se houver algum problema com o jogo, como descobrir em qual pacote devo enviar um relatório de erros?

Então, a primeira coisa que faço ao tentar solucionar problemas de um aplicativo GUI é pegar seu ícone e colocá-lo no painel e ver suas propriedades exatamente como eu estou mostrando aqui -

Agora eu sei que o nome do aplicativo. não é Aiselriot mas sol e o caminho onde o aplicativo é colocado está em /usr/games/sol .

Agora vamos tentar encontrar o que o pacote é chamado -

dpkg -S /usr/games/sol

A saída é:

aisleriot: / usr / games / sol

Temos a sorte que o pacote também é chamado aiselriot, mas isso não acontece o tempo todo.

Continuando, vamos agora relatar nosso primeiro relatório de erros. Como estou usando o Debian testing / stretch / em breve para ficar estável em poucos meses, vou colocar um bug-report por lá.

Etapa 6. Usando Reportbug para fazer um relatório de bug

Agora precisamos de um pacote que tenha um problema / bug que precisemos reportar para a comunidade Debian.

Eu tenho um pacote piuparts que mostrou sintomas de um problema para o qual eu voltei para Reportbug como mostrado na essência:

Agora deixe-me explicar como as coisas estão funcionando. Eu uso uma ferramenta chamada adequada (que é uma ferramenta de verificação de pacotes Debian) ao instalar pacotes. Vou falar sobre o adequado em detalhes em algum post futuro do blog.

O que o Reportbug faz é obter e analisar todas as informações que ele tem sobre o pacote, para saber se deve prosseguir ou não.

Agora, a ferramenta adequada é executada em segundo plano o tempo todo. Um dos seus principais trabalhos ocorre logo no final de uma instalação de pacote, por exemplo, para piuparts compartilha / me mostrou isso -

adequate found packaging bugs

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

piuparts: obsoleto-conffile / etc / piuparts / scripts / post_setup_experimental

que me disse que o pacote piuparts tinha um conffile obsoleto. Conffile significa arquivo de configuração.

Então o primeiro comando que eu faço sempre que encontro um bug que vale a pena ser reportado é que eu faço isso -

reportbug piuparts --severity=normal

Dá / fala sobre o pacote que tem o problema, neste caso piuparts.

Colocar severidade em qualquer bug é um negócio complicado. A menos que eu tenha sentimentos muito fortes sobre um pacote e saiba, sem sombra de dúvida, que o bug é realmente severo, eu não levanto a gravidade. Esta é minha própria ética pessoal, também um pouco menos trabalho para um mantenedor.

Dito isto, a maioria dos mantenedores olharia para um bug, independentemente da gravidade que você desse. Eu tive mantenedores me respondendo rapidamente, mesmo quando eu tinha arquivado bugs de wishlist e tenho mantenedores que não voltam. MIA (Missing-in-Action), mesmo após a apresentação de bugs graves. Arquivar e ter uma conversa saudável com o mantenedor é uma atividade técnica e social.

Depois de perguntar ao assunto, o reportbug pergunta / dá várias opções se uma das condições se aplicar. Você poderia usar qualquer um se achar que seu bug foi afetado ou afeta uma das coisas acima na lista. Por exemplo, se você for compartilhar um patch para corrigir o problema, você escolherá 6 ou um dos outros. Se nenhum deles for necessário, basta entrar e seguir em frente.

Uma vez que o acima é feito, leva alguns instantes e temos algo semelhante a esta essência compartilhada:

Agora, o que isso faz é dar uma idéia ao mantenedor do estado do seu sistema. Como todos sabem, quase todas as distribuições GNU / Linux e os pacotes são baseados em um conjunto complexo de relacionamentos com outros pacotes. O mantenedor precisa saber qual versão do pacote você estava usando, quais outros pacotes estavam lá, em que versão eles estavam, além de saber que a integridade do pacote não foi adulterada de forma alguma.

Agora você precisa preencher os bancos -

Eu costumo remover / excluir o seguinte, se você é um novo usuário, você poderia apenas responder as perguntas abaixo e seu relatório de erros estaria pronto.

Etapa 7. As alterações finais feitas para passar o relatório

E em seu lugar, eu coloquei os detalhes como sendo compartilhados aqui:

Mais algumas informações. agora - Essas duas tags sinalizam / dizem aos mantenedores poucas coisas -

Usuário: [email protected]

A primeira tag está sinalizando que o bug sendo gerado faz parte dos esforços do debian-qa.

Usertags: obsolete-conffile adequate

A segunda tag está dizendo a ferramenta que usamos e um dos problemas comuns sob os quais ela veio - neste caso, conffile obsoleto.

Há poucos casos de uso comuns e incomuns que são considerados adequadamente. Como compartilhado anteriormente, será necessário outro post para compartilhar sobre isso em detalhes.

A outra coisa que estou dizendo / compartilhando o mantenedor é que ele deve estar procurando no debhelper (um kit de ferramentas para o debian / rules) e procurar por bits específicos nele.

Dica - Paul Wise, mais conhecido como pabs na comunidade Debian. Ele é um colaborador prolífico do Debian. Como você pode ver na sua página wiki e nos aplicativos secundários. Ele sempre tem uma lista interminável de aplicativos, pacotes que seriam interessantes de se empacotar com coisas que poderiam / precisavam ser melhoradas. Eu não sei se ele fez qualquer orientação ou não, vejo sinais de um mentor bom e bobo nele. Eu às vezes pergunto, às vezes roubo suas idéias para ajudar no Debian QA :)

Agora, que o relatório de erros está completo, tenho que enviá-lo via gmail.com. Se você tiver habilitado o MTA (Mail Transfer Agent) e não tiver um gmail.com, você pode simplesmente enviar e isso será feito. Se, por outro lado, você não tiver habilitado o MTA (como eu) e gostar de fazer as coisas sozinho, faça o login na sua conta do gmail, clique em compor e depois -

Passo 8. O passo final

To - [email protected]

Assunto - piuparts: relatórios adequados obsoletos conffile para piuparts

O corpo do seu email deve começar com o pacote

algo assim -

Você deve ter notado alguns rótulos, eles são apenas para me ajudar a ser um pouco organizado, pois depois de você ter relatado alguns bugs, pode se tornar caótico saber o que está acontecendo. Os marcadores e os filtros do Gmail diminuem um pouco a quantidade de e-mails que recebo.

Nesse ponto, lembre-se de verificar novamente o e-mail mais uma vez antes de clicar no botão enviar e-mail. Eu costumo clicar em salvar rascunho, revê-lo uma ou duas vezes antes de enviá-lo.

Se você está satisfeito, clique em enviar e seu relatório de erros será enviado para o Debian BTS.

Etapa 9. Obtendo o reconhecimento do servidor BTS do Debian informando que o bug chegou até eles.

Normalmente, em poucos minutos recebo uma mensagem de confirmação curta do Debian BTS, como na essência que está sendo compartilhada

Olhe para o carimbo de data / hora dado, apenas a 3 minutos de distância de quando o e-mail foi enviado. Enviei o e-mail de bug em 05:03 e recebi a resposta automática dizendo que tudo correu bem em 05:06 em si.

O que eu procuro no e-mail de confirmação é o número do bug, pois é assim que eu sei como as coisas estão indo com o bug.

# 854317

Poste o ciclo de relatório de erros.

Coincidentemente, como pode ser visto, o mantenedor do pacote de alguma forma estava na época em que eu arquivei o bug. Eu sei a importância do piuparts no ecossistema debian, mas eu não acho que o Andreas irá agir tão rapidamente, então agora, provavelmente, o próximo lançamento do ponto ou mesmo o lançamento da correção do bug terão a correção. Como pode ser visto, Andreas parece ser uma abelha ocupada vendo o número de pacotes que ele mantém / co-mantendo, além de fazer o upload de Uploads que não são mantenedores (NMU) e uploads de QA.

Espero ter dado insights suficientes para que você saiba o que fazer quando e como as coisas dão errado.

Dica - Atualmente, costumo seguir algumas regras antes de preencher um bug. Primeiro verifique o bts para a lista existente de bugs, por exemplo, a página de bugs do piuparts (como também compartilhada por Simon Tatham acima). Se o bug não estiver listado lá, na maioria das vezes, o pacote não tem muitas dependências, e eu sei que não há arquivos de configuração que eu precise recriar, então eu geralmente limpo o pacote e instalo o pacote novamente. Se o suficiente ainda encontrar uma falha, eu geralmente o denuncio. Eu não faço isso para conffiles obsoletos como eles geralmente acontecem quando você está atualizando da versão x.1 para x.2 ou algo parecido.

Usando essas dicas simples, economizo tempo e energia para mim e para o mantenedor de um pacote.

No começo, pode levar algum tempo, depois de um tempo, a coisa toda pode levar de 10 a 15 minutos ou até menos, dependendo do pacote em que o bug é encontrado, o bug em si, a replicação do bug, etc.

É sobre isso fazer um relatório de erros no Debian usando o Reportbug.

Espero que você tenha alguma idéia dos passos para encontrar bugs e relatá-los. Por favor, poste qualquer dúvida que você tenha nos comentários abaixo e tentarei o meu melhor para responder / compartilhar qualquer coisa que eu saiba.

Recomendado

Conferência de Código Aberto da Albânia está à procura de palestrantes
2019
Dois eventos de código aberto a serem realizados no Reino Unido
2019
Como criar um aplicativo da Web para o telefone do Ubuntu
2019