Escrevendo Relatórios de Problema no FreeBSD

4.1. Dicas e truques para escrever um bom relatório de problema.

• Não deixe a linha de “Synopsis” (sinopse) em branco. Os PRs são enviados para listas de discussão no mundo todo (nas quais a “Synopsis” é utilizada como linha de Subject:), além de serem armazenados em um banco de dados. Qualquer pessoa que vier a navegar no banco de dados pelas sinopses, e encontrar um PR com a linha de assunto em branco, tende a pulá-lo. Lembre-se que os PRs permanecem na base de dados até que sejam fechados por alguém; os anônimos normalmente irão desaparecer em meio ao ruído.

• Evite utilizar uma “Synopsis” (sinopse) fraca. Você não pode assumir que alguém que esteja lendo o seu PR conheça todo o contexto que motivou o seu envio, desta forma quanto mais informação você fornecer, melhor. Por exemplo, a que parte do sistema o problema se aplica? O problema ocorre durante a instalação ou durante a execução do sistema? Para ilustrar, ao invés de utilizar Synopsis: o portupgrade está quebrado, veja o quão mais claro e mais eficiente seria utilizar Synopsis: port sysutils/portupgrade gerando coredumps no -current. (No caso de um port, é especialmente útil ter a categoria e o nome do port na linha de sinopse.)

• Se você possui um patch, mencione-o. Um PR que inclui um patch é muito mais provável de ser analisado do que um sem. Se você estiver incluindo um, coloque a palavra [patch] no inicio da linha de sinopse. (Embora não seja obrigatório utilizar exatamente esta palavra, por convenção, é ela que é utilizada.)

• Se você é um maintainer (mantenedor), diga-o. Se você está mantendo uma parte do código fonte (por exemplo, um port), você deve considerar a possibilidade de incluir as palavras [maintainer update] (incluindo os colchetes) no inicio da linha de sinópse e deve definir a “class” (classe) do seu PR para maintainer-update. Desta forma qualquer committer que manusear o seu PR não terá de verificar o Makefile do port, para certificar-se de que a atualização foi enviada pelo maintainer.

• Seja específico. Quanto mais informações você fornecer sobre o problema que você está tendo, melhores serão as suas chances de obter uma resposta.

  • Inclua a versão do FreeBSD que você está utilizando (existe um lugar para colocar esta informação, veja abaixo) e em qual arquitetura. Você incluir a informação se está executando a partir de um Release (e.g. de um CDROM ou Download), ou a partir de um sistema mantido com o cvsup(1) (e neste caso, quando foi atualizado pela ultima vez). Se você estiver utilizando o FreeBSD-CURRENT, esta vai ser a primeira coisa que alguém irá lhe perguntar, porque as correções (especialmente para os problemas de alto nível) tendem a serem realizadas muito rapidamente, e espera-se que os usuários do FreeBSD-CURRENT mantenham-se atualizados.

  • Inclua quais opções globais você especificou no seu make.conf. Observação: É conhecido que utilizar -O2 (e acima disso) com o gcc(1) gera problemas em muitas situações. Apesar dos desenvolvedores do FreeBSD aceitarem patches, eles normalmente não estão dispostos a investigar este tipo de problema por uma simples falta de tempo e de voluntários, e ao invés disso podem responder apenas que isto não é suportado.

  • Se o problema pode ser reproduzido facilmente, inclua informações para possibilitar que ele seja reproduzido pelos desenvolvedores. Se o problema só pode ser demonstrado com a entrada de um conjunto de dados específico, você deverá incluir um exemplo destas informações, além de informar qual é resultado atual (errado) e qual era o resultado esperado (correto). Se o conjunto de dados for muito grande ou se o mesmo não puder ser tornado público, tente criar um arquivo com o mínimo de informações necessárias para replicar o problema, e que possa ser incluído no seu PR.

  • Se for um problema com o kernel, esteja preparado para fornecer as seguintes informações (Você não precisa fornecer estas informações por padrão, o que só tende a encher o banco de dados, mas você deve incluir os trechos acreditar que são relevantes):

    • A configuração do seu kernel (incluindo quais dispositivos de hardware você tem instalados)

    • Se você tem ou não opções de depuração habilitadas (tais como WITNESS), e em caso afirmativo, se o problema continua ocorrendo quando você altera a lógica de configuração destas opções

    • O texto completo de qualquer backtrace, panic e outras mensagens no console, ou os registros do /var/log/messages, caso tenha sido gerado algum

    • A saída do pciconf -l e as partes relevantes da saída do dmesg se o problema estiver relacionado a um componente de hardware

    • O fato de que você leu o src/UPDATING e que o seu problema não está listado ali (é certeza que alguém vai perguntar)

    • Se você consegue ou não executar outro kernel (Isto é para poder descartar a possibilidade de ser um problema de hardware tais como falha nos discos rígidos e superaquecimento dos processadores, cujos sintomas podem se confundir com problemas no kernel)

  • Se for um problema com um port, esteja preparado para fornecer as seguintes informações (Você não precisa fornecer estas informações por padrão, o que só tende a encher o banco de dados, mas você deve incluir os trechos acreditar que são relevantes):

    • Quais ports você tem instalados

    • As variáveis de ambiente que substituem os padrões do bsd.port.mk, como por exemplo PORTSDIR

    • O fato de que você leu o ports/UPDATING e que o seu problema não está listado ali (é certeza que alguém vai perguntar)

• Evite pedidos vagos de novas funcionalidades. Os PRs no formato “alguém realmente deveria implementar algo que faz isso e aquilo” são menos prováveis de obterem uma resposta do que os que são mais específicos. Lembre-se, o código está disponível para todos, de forma que se você deseja uma nova funcionalidade, a melhor maneira de ter certeza de que ela será incluída é começar a trabalhar! Também considere o fato de que muitas destas sugestões fariam mais sentido como um tópico de discussão na freebsd-questions do que como uma entrada no banco de dados de PRs, como discutido acima.

• Certifique-se de que ninguém tenha submetido um PR semelhante antes. Embora isso já tenha sido mencionado anteriormente, faz sentido repetir aqui. Esta verificação irá lhe tomar apenas 1 ou 2 minutos no uso do mecanismo de busca do banco de dados de PRs. (é claro, todos são culpados de já terem esquecido de fazer isso de uma vez ou outra.)

• Relate apenas um problema em cada relatório. Evite incluir dois ou mais problemas em um mesmo relatório caso eles não estejam relacionados. Quando você submeter um patch, evite adicionar várias funcionalidades ou corrigir vários bugs em um mesmo PR, a menos que eles sejam estritamente relacionados — Este tipo de PR muitas vezes demanda mais tempo para ser resolvido.

• Evite solicitações polêmicas. Se o seu PR está relacionado a um tema que foi polêmico no passado, você deve estar preparado para não somente disponibilizar um patch, como também para defender porque o seu patch é “a coisa certa a se fazer”. Como mencionado acima, realizar uma busca cuidadosa no histórico das listas de discussão é sempre uma boa forma de se preparar.

• Seja educado. Praticamente todas as pessoas que potencialmente podem trabalhar no seu PR são voluntários. Ninguém gosta de receber ordens para fazer algo que eles já estão fazendo por alguma outra motivação a qual não é a de ganho financeiro. Esta é uma boa coisa para ter sempre em mente num projeto de código aberto.

4.2. Antes de você iniciar

Antes de executar o programa send-pr(1), certifique-se que a sua variável de ambiente VISUAL (ou a EDITOR se a VISUAL não estiver definida) está definida com seu editor preferido.

Você também deve certificar-se de que o seu sistema de entrega de emails esta funcionando corretamente. O send-pr(1) utiliza mensagens de email para enviar e rastrear um relatório de problema. Se você não pode enviar mensagens de email a partir da máquina na qual está executando o send-pr(1), os seus relatórios de problema não irão chegar até a base de dados GNATS. Para maiores detalhes de como configurar o sistema de email no FreeBSD, consulte o capítulo sobre “Correio Eletrônico” no Handbook do FreeBSD.

Certifique-se de que o seu sistema de email não irá alterar a formatação da mensagem ao encaminhá-la para o GNATS. Qualquer patch que você enviar será inutilizado, caso o seu sistema de email quebre automaticamente as linhas, troque tabulações por espaços em branco ou altere os caracteres de mudança para uma nova linha, etc. Entretanto, para as seções de texto nós pedimos que você quebre manualmente as linhas próximo dos 70 caracteres, desta forma a versão web do PR poderá ser lida melhor.

Considerações similares se aplicam se você estiver utilizando o formulário web de submissão de PR ao invés de utilizar o send-pr(1). Observe que operações de copiar-e-colar possuem seus próprios efeitos colaterais na formatação do texto. Em certos casos, pode ser necessário usar o uuencode(1) para garantir que os patches cheguem sem modificações.

Finalmente, se a sua submissão será longa, você deve preparar o texto do seu relatório offline, desta forma nada será perdido no caso de você ter problemas quando for submetê-lo. Isto pode ser um problema, em especial, se você estiver utilizando o formulário web.

4.3. Anexando patches ou arquivos

As instruções abaixo se aplicam ao envio de PRs por email:

O programa send-pr(1) tem a capacidade de anexar arquivos em um relatório de problemas. Você pode anexar quantos arquivos desejar desde que os mesmos possuam nomes únicos (i.e. o nome próprio do arquivo, sem o caminho de diretório). Basta usar a opção -a na linha de comando para anexar os arquivos desejados:

% send-pr -a /var/run/dmesg -a /tmp/errors

Não se preocupe com os arquivos binários, eles serão encodados automaticamente de forma a não perturbar o seu agente de correio.

Se você anexar um patch, tenha certeza de utilizar a opção -c ou -u no diff(1) para criar um diff contextual ou um diff unificado (o formato unificado é preferido), e tenha certeza de especificar os números de revisão exatos dos arquivos que você modificou, desta forma o desenvolvedor que ler seu relatório terá condições de aplicá-los facilmente. Para problemas com o kernel ou com os aplicativos do sistema base, um patch para o FreeBSD-CURRENT (o ramo HEAD do CVS) é preferido uma vez que todo novo código deve ser aplicado e testado primeiro nele. Depois que forem realizados os testes apropriados, o código será fundido ou migrado para o ramo FreeBSD-STABLE.

Se você juntar um patch no corpo do email, em vez de enviá-lo como um arquivo anexo, você estará sujeito a ocorrência de um problema bastante comum ocasionado pela tendência de alguns clientes de email de converter tabs em espaços, o que irá arruinar completamente qualquer coisa que você tenha enviado com intenção de que fosse parte de um Makefile.

Não envie patches como anexos usando Content-Transfer-Encoding: quoted-printable . Isto irá realizar character escaping e o patch inteiro estará inutilizado.

Observe também que incluir pequenos patches em um PR é normalmente a coisa certa a se fazer — particularmente quando ele corrige o problema descrito no PR — grandes patches e especialmente código novo, que normalmente requerem uma revisão substancial antes de serem incorporados, devem ser colocados em um servidor web ou de FTP, e a url deve ser incluída no PR ao invés do patch propriamente dito. Os patches dentro de um email tendem a se deformar, especialmente quando o GNATS está envolvido, e quanto maior o patch, maior é a dificuldade para ambas as partes em consertá-lo. Além de que, ao colocar o patch na web, você pode modificá-lo sem ter que reenviar o arquivo completo como um followup do PR original. Além disso, os grandes patches simplesmente aumentam o tamanho do banco de dados, uma vez que os relatórios de problema fechados não são deletados, continuando a existir marcados como closed.

Você deve observar que a menos que especifique explicitamente no seu PR ou diretamente no seu patch, qualquer correção que você envie será considerada como estando licenciada sob os mesmos termos do arquivo original que você modificou.

4.4. Preenchendo o template

As instruções abaixo se aplicam apenas ao envio de PRs por email:

Quando você executar o programa send-pr(1), você será apresentado a um template. O template consiste em uma lista de campos, alguns dos quais estarão pré-preenchidos, e alguns irão possuir comentários explicando o seu propósito ou então listando os valores aceitáveis. Não se preocupe com os comentários, eles serão removidos automaticamente se você não modificá-los ou então os remova você mesmo.

Na parte superior do template, logo abaixo das linhas SEND-PR:, está o cabeçalho do email. Você normalmente não necessita modificá-lo, a menos que você esteja enviando o relatório de problema a partir de uma máquina ou de uma conta a qual pode enviar, mas não pode receber emails, neste caso você deve configurar manualmente os campos From: e Reply-To: para o seu endereço de email real. Você também pode querer enviar uma cópia do relatório para você mesmo (ou para alguma outra pessoa) através do uso de uma cópia carbono, adicionando um ou mais endereços de email na linha de cabeçalho Cc:.

Os campos de linha única descritos abaixo, estão disponíveis apenas no template do email:

• Submitter-Id: Não altere este campo. O valor padrão é current-users e está correto, mesmo se você estiver executando o FreeBSD-STABLE.

• Confidential: Não altere este campo. O valor padrão é no. Não tem sentido alterá-lo já que não existem relatórios de problema confidenciais no FreeBSD — o banco de dados de PR é distribuído mundialmente pelo CVSup.

• Severity: Escolha uma opção entre non-critical, serious ou critical. Não faça escândalo; abstenha-se de rotular seu problema como critical a menos que ele realmente seja (por ex. questões de corrupção de dados, grave retrocesso de funcionalidade no -CURRENT em relação a versão anterior, etc)ou de serious a menos que seja algo que vai afetar muitos usuários (Kernel panic ou travamentos do sistema; Problemas com algum driver de dispositivo em particular ou com utilitários de sistema). Os desenvolvedores do FreeBSD não irão necessariamente trabalhar no seu problema mais rápido se você inflar sua importância uma vez que existem muitas outras pessoas que fizeram exatamente isso — na verdade, alguns desenvolvedores prestam pouca atenção a este campo por causa disso.

  Nota: Problemas de segurança não devem ser submetidos para o GNATS, pois todas as informações no GNATS são de conhecimento público. Por favor, envie estes problemas seguindo as nossas diretrizes sobre relatórios de segurança.

• Priority: Escolha uma opção entre low, medium ou high. high deve ser reservada para os problemas que afetam praticamente todos os usuários do FreeBSD e medium para os problemas que vão afetar muitos usuários.

  Nota: Este campo tornou-se tão amplamente abusado que perdeu quase que completamente seu objetivo.

A próxima seção descreve os campos que são comuns entre a interface por email e a interface web:

• Originator: Por favor informe seu nome completo, seguido opcionalmente pelo seu endereço de email entre colchetes. Na interface de email, este campo é normalmente pré-preenchido com o campo gecos do usuário com o qual você está atualmente logado.

  Nota: O endereço de email que você utilizar irá se tornar uma informação pública e pode vir a se tornar disponível para spammers. Você deverá ter um sistema antispam funcional ou então deverá utilizar uma conta temporária de email. Contudo, por favor, lembre-se que se você não utilizar uma conta de email válida, nós não seremos capazes de entrar em contato com você para fazer perguntas sobre o seu PR.

• Organization: Campo livre para o que você quiser colocar. Este campo não é utilizado para nada significativo.

• Synopsis: Preencha este campo com uma descrição curta e precisa sobre o seu problema. A synopsis é utilizada como o assunto do email do relatório de problema, e também é utilizada na listagem de relatório de problemas e resumos; relatórios de problema com synopses obscuras tendem a serem ignorados.

  Como mencionado acima, se o seu relatório de problema inclui um patch, por favor, inicie sua synopsis com [patch] (incluindo os colchetes); se você for um maintainer considere adicionar [maintainer update] (incluindo os colchetes) ao início da sua synopsis e defina a “classe” do seu PR para maintainer-update.

• Category: Escolha uma categoria adequada.

  A primeira coisa que você precisa fazer é decidir em qual parte do sistema o seu problema está. Lembre-se, o FreeBSD é um sistema operacional completo, o qual instala um kernel, as bibliotecas padrão, muitos drivers de dispositivos e um grande número de utilitários (este conjunto recebe o nome de “sistema base”). No entanto, existem milhares de aplicativos adicionais na Coleção de Ports. Você primeiro precisa decidir se o problema está no sistema base ou se está em algo que foi instalado através da Coleção de Ports.

  Aqui está uma descrição das principais categorias:

  • Se o problema é com o Kernel, com as bibliotecas (tal como a biblioteca C padrão, libc), ou com um driver de dispositivo do sistema base, em geral você vai usar a categoria kern. (Existem algumas exceções; veja abaixo). Em geral, estas são coisas que estão descritas nas seções 2, 3 ou 4 das páginas de manual.

  • Se o problema é com um programa binário, tal como o sh(1) ou o mount(8), primeiro você precisa determinar se estes programas pertencem ao sistema base ou se foram adicionados através da coleção de ports. Se você estiver na dúvida, você pode executar um whereis nomedoprograma, no FreeBSD por convenção todos os aplicativos da coleção de ports são instalados sob /usr/local, embora isso possa ser alterado por um administrador de sistemas. Para estes, você irá utilizar a categoria ports (sim, mesmo que a categoria do port seja www; veja abaixo). Se a localização do aplicativo for /bin, /usr/bin, /sbin, ou /usr/sbin, ele faz parte do sistema base, e você deverá utilizar a categoria bin. (Alguns programas, como o gcc(1), na prática utilizam a categoria gnu, mas não se preocupe com isso por agora.) Todos estes aplicativos estão descritos nas seções 1 ou 8 das páginas de manual.

  • Se você acredita que o erro está no script de inicialização (rc), ou em algum outro tipo de arquivo de configuração não executável, então a categoria indicada será a conf (configuração). Estas são coisas descritas na seção 5 das páginas de manual.

  • Se você encontrou um problema na documentação (artigos, livros, páginas de manual, etc.), a escolha correta para a categoria é a opção docs.

  • Se você está tendo problemas com as páginas web do FreeBSD, a escolha apropriada é www.

    Nota: Independentemente se você está tendo algum problema com um port chamado www/nomedoport, a categoria correta para o mesmo será ports.

  Existem algumas categorias mais especializadas.

  • Se o problema pode ser classificado na categoria kern, e está relacionado ao subsistema USB, a categoria correta será usb.

  • Se o problema pode ser classificado na categoria kern, e está relacionado com as bibliotecas de threads, a categoria correta será threads.

  • Se o problema está localizado no sistema base, mas está relacionado a nossa aderência a padrões tais como o POSIX®, a categoria correta será standards.

  • Se o problema está relacionado a erros internos de uma Java Virtual Machine™ (JVM™), mesmo que o Java™ tenha sido instalado a partir da coleção de ports, você deve selecionar a categoria java. Problemas genéricos com o port do Java devem continuar sendo enviados na categoria ports.

  Isto deixa tudo mais.

  • Se você está convencido de que o problema irá ocorrer apenas na arquitetura do processador que você está utilizando, selecione uma categoria específica para a sua arquitetura: geralmente i386 para máquinas compatíveis com a arquitetura Intel de 32 bits, amd64 para máquinas AMD executando em modo 64 bits (o que também inclui máquinas compatíveis com a arquitetura Intel executando em modo EMT64); e menos comumente ia64, powerpc, e sparc64.

    Nota: Estas categorias são muitas vezes utilizadas de forma indevida para problemas do tipo “Eu não sei”. Em vez de tentar adivinhar, por favor, apenas utilize a categoria misc.

    Exemplo 1. Uso correto da categoria específica de arquitetura.

    Você tem um computador comum (PC), e acredita que encontrou um problema específico com um chipset em particular ou com uma placa mãe específica: A categoria correta é i386.

    Exemplo 2. Uso incorreto da categoria específica de arquitetura.

    Você está tendo problemas com uma placa de expansão instalada em um barramento bastante comum, ou um problema com um tipo específico de disco rígido: neste caso, é provável que o problema ocorra em mais de uma arquitetura, e a categoria correta seria kern.

  • Se você realmente não sabe onde está o problema (ou o mesmo não parece se encaixar nas categorias acima), utilize a categoria misc. Mas antes de fazer isto, pode ser uma boa idéia primeiro pedir ajuda na lista de discussão para perguntas gerais sobre o FreeBSD. Você poderá ser orientado à utilizar uma das outras categorias para obter um melhor resultado.

  Aqui está a lista atual de categorias (retirada do url http://www.FreeBSD.org/cgi/cvsweb.cgi/src/gnu/usr.bin/send-pr/categories):

  • advocacy: problemas relacionados a imagem pública do FreeBSD. Obsoleta.

  • alpha: problemas específicos da plataforma Alpha.

  • amd64: problemas específicos da plataforma AMD64.

  • arm: problemas específicos da plataforma ARM.

  • bin: problemas com os programas de nível de usuário na base do sistema.

  • conf: problemas com os arquivos de configuração, valores padrões, etc.

  • docs: problemas com as páginas de manuais ou com a documentação online.

  • gnu: problemas com softwares GNU, tais como gcc(1) ou grep(1).

  • i386: problemas específicos da plataforma i386™.

  • ia64: problemas específicos da plataforma ia64.

  • java: problemas relacionados com a Maquina Virtual Java.

  • kern: problemas com o kernel, drivers de dispositivo (não específicos à uma plataforma), ou bibliotecas do sistema base.

  • misc: Tudo aquilo que não se encaixa numa das outras categorias. (observe que não existe nada que pertença verdadeiramente a esta categoria, exceto os problemas com a infra estrutura de build e de release. As falhas temporárias de compilação do HEAD não pertencem a esta categoria. Também observe que é fácil para as coisas se perderem nesta categoria).

  • ports: problemas relacionados com a Coleção de Ports.

  • powerpc: problemas específicos da plataforma PowerPC®.

  • sparc64: problemas específicos da plataforma SPARC64®.

  • standards: problemas relacionados a conformidade com os padrões.

  • threads: problemas relacionados a implementação de threads no FreeBSD (especialmente no FreeBSD-CURRENT).

  • usb: problemas relacionados a implementação do USB no FreeBSD.

  • www: mudanças e melhorias no web site do FreeBSD.

• Class: Escolha uma das seguintes opções:

  • sw-bug: bugs de software.

  • doc-bug: erros na documentação.

  • change-request: solicitação de novas funcionalidades ou de alterações em funcionalidades existentes.

  • update: atualizações para o ports ou para outros softwares de terceiros.

  • maintainer-update: atualizações de ports pelos quais você é o responsável.

• Release: É a versão do FreeBSD que você está utilizando. Este campo é preenchido automaticamente pelo send-pr(1) e só necessita ser alterado se você estiver enviando o relatório de problema de um sistema diferente do que apresenta o problema.

Finalmente, há uma série de campos de várias linhas:

• Environment: Este campo deve descrever, da forma mais precisa possível, o ambiente no qual o problema foi observado. Isto inclui a versão do sistema operacional, a versão do programa ou do arquivo específico que contém o problema, e qualquer outro item relevante tal como a configuração do sistema, outros softwares instalados que tenham influência no problema, etc. — ou seja, simplesmente tudo o que um desenvolvedor precisar saber para reconstruir o ambiente no qual o problema ocorreu.

• Description: Uma descrição precisa e completa do problema que você esta experimentando. Tente evitar especular sobre as causas do problema a menos que você tenha certeza de que está no caminho certo, do contrário você pode induzir o desenvolvedor a fazer suposições incorretas sobre o problema.

• How-To-Repeat: Um resumo com as ações que você precisa executar para reproduzir o problema.

• Fix: Preferencialmente um patch, ou no mínimo um workaround (o que não só ajuda as outras pessoas que estão com o mesmo problema, como também auxilia o desenvolvedor a entender melhor a causa do problema), mas se você não tem nenhuma idéia consistente, é melhor deixar este campo em branco do que especular.

4.5. Enviando o relatório de problemas

Se você está utilizando o send-pr(1):

Uma vez que você tenha terminado de preencher o template, salve-o, e saia do editor de texto, ao fazer isto o send-pr(1) irá lhe perguntar se você deseja s)end, e)dit or a)bort?. Para ir em frente e enviar o relatório de problema pressione s, caso você queira voltar ao editor para realizar alguma alteração pressione e, ou então pressione a para cancelar o envio. Se você optar por abortar, o seu relatório de problema irá permanecer no seu disco rígido (o send-pr(1) irá lhe informar o nome do arquivo antes de finalizar), assim você poderá editá-lo quando for mais conveniente, ou poderá transferi-lo para um sistema com uma melhor conectividade, no qual poderá enviá-lo usando a opção -f com o send-pr(1):

% send-pr -f ~/my-problem-report

Este comando irá ler o arquivo especificado, validar o seu conteúdo, remover os comentários e enviar o seu PR.

Se você está utilizando o formulário web:

Antes de pressionar o botão submit para enviar o seu relatório, você terá que preencher um campo com o texto exibido na imagem de captcha exibida no final do formulário. Infelizmente esta medida teve de ser adotada devido ao mau uso do mesmo por sistemas automatizados e por alguns indivíduos mal intencionados. É um mal necessário do qual ninguém gosta. Por favor, não peça para removê-lo.

Recomendamos fortemente que você salve o seu trabalho em algum outro lugar antes de pressionar o botão submit. Um problema comum e que ocorre com muitos usuários é a visualização de uma imagem de captcha velha exibida a partir do cache do navegador. Se isso acontecer com você o seu envio será rejeitado e você poderá perder o seu trabalho.

Se você, por qualquer motivo, não conseguir visualizar as imagens, e também estiver impossibilitado de utilizar o send-pr(1), por favor, aceite nossas desculpas por está inconveniência e envie seu relatório de problema por e-mail para a equipe de bugbusters do FreeBSD, no endereço <freebsd-bugbusters@FreeBSD.org>.