FAQ empacotamento Debian

Este FAQ é um complemento para a página Algumas coisas sobre Debian..., disponível em http://debianet.com.br.

Esta página também poderá ser acessada pelo endereço http://eriberto.pro.br/debian/faq.html.

Dúvidas iniciais

Preciso ser programador para empacotar no Debian?

Em resumo, NÃO!

Você precisa conhecer Debian, um pouquinho de shell script (bem básico), além de saber compilar e instalar programas. No fim, você disponibilizará executáveis prontos para usuários finais, dentro de um arquivo .deb, que é um arquivo compactado com 'ar'. Como experiência, você pode executar um '$ ar -x pacote.deb' para ver o seu conteúdo.

Programar ajuda a sanar determinados problemas e fazer melhorias além do básico. No entanto, não ser programador não impede ninguém de ser empacotador. Várias pessoas que mantêm pacotes no Debian não são programadores.

Onde posso aprender a empacotar?

A documentação oficial é o Guia dos Novos Mantenedores, disponível em https://www.debian.org/devel (em HTML). Ele também está disponível em outros formatos e idiomas aqui.

Para quem fala português, há videoaulas disponíveis em http://debianet.com.br.

Outra possibilidade interessante é de inscrever-se na lista Debian Mentors, destinada a retirar dúvidas de quem empacota ou está começando e acompanhá-la.

Obtenção de um sponsor

O que é um sponsor?

É um desenvolvedor Debian (DD) que, voluntariamente, poderá analisar o seu pacote e fazer upload do mesmo para o Debian, uma vez que somente membros oficiais podem fazer upload.

Para onde envio o meu pacote quando estiver pronto?

• Inicialmente, crie uma conta no site http://mentors.debian.org.
• Você também vai precisar de uma chave GPG RSA de 4096 bits. Para isso siga as instruções existentes em https://wiki.debian.org/Keysigning. Siga os passos 1 a 7 COM ATENÇÃO.
• Envie o seu pacote para o mentors, usando o comando dput mentors. Instruções aqui.
• A seguir, busque por um sponsor. O sponsor é um Debian Developer (Desenvolvedor Debian, ou DD) que fará o upload do seu pacote para o Debian. Você poderá encontrar um no mundo (mais sponsors disponíveis) ou no Brasil. Veja como:
  • No mundo: crie um bug para o pacote virtual sponsorship-requests. Siga fielmente as instruções que estão aqui. Note que o próprio site mentors criará um template para você usar para o seu RFS (Request For Sponsor). Basta entrar na página que mostra o pacote do qual foi feito upload e procurar por View RFS template.
  • No Brasil: inscreva-se na lista Debian Devel Portuguese. A seguir, envie um email solicitando que alguém revise o seu pacote, dizendo o nome, o que ele faz e o endereço no mentors.

Obs: todos os DDs estão cadastrados aqui.

Há condições mínimas que que eu solicite um sponsor?

Sim. Um sponsor trabalha de forma voluntária, dedicando o seu tempo, sem receber nada por isso. Então:

• Não envie pacotes mal feitos ou cheios de mensagens de lintian que podem ser sanadas. O seu pacote será sumariamente ignorado.
• Não envie várias mensagens seguidas pedindo um sponsor. Por se tratar de um trabalho voluntário, você deve esperar pela disponibilidade de alguém. Você poderá enviar uma nova mensagem depois de muito tempo (um mês é uma boa medida). Mas, normalmente, os pedidos são atendidos rapidamente.
• Seja sempre cordial com quem está dedicando tempo para lhe ajudar.
• Se for o caso, antes de enviar um pacote, retire todas as suas dúvidas nos canais destinados a isso. Veja o item Onde posso obter ajuda, retirar dúvidas sobre empacotamento?

Progresso do empacotamento

Como o meu pacote e o meu nome serão mostrados no Debian?

Vamos às possibilidades:

• Depois que um DD fizer o upload para você, o pacote com o seu nome poderá ser visto em https://tracker.debian.org.
• Após o seu primeiro upload, o seu nome será registrado aqui. Pode demorar até 1 mês para o seu nome aparecer.
• O seu último upload sempre aparecerá aqui. Essa lista é atualizada a cada mês.
• O seu nome também será mostrado neste rancking.
• Se o seu pacote for novo no Debian, no dia seguinte à aprovação o nome dele aparecerá aqui.
• Após algum tempo, o seu pacote também aparecerá aqui.
• Se você for dono de pacotes, verá o seu nome aqui também.
• No momento em que o pacote entrar no unstable ou na experimental, ele será mostrado na lista debian-devel-changes.

Quando você tiver um pacote, será criada uma página específica para você, cujo endereço será https://qa.debian.org/developer.php?login=<seu email>. Clique aqui para ver a minha página como exemplo.

Onde posso obter ajuda, retirar dúvidas sobre empacotamento?

Há várias opções para você poder retirar as suas dúvidas on-line.

• Lista Debian Mentors: esta é uma lista internacional, destinada especificamente à retirada de dúvidas sobre empacotamento.
• Canal #debian-mentors no IRC irc.debian.org, porta 9999 (com SSL) ou 7000 (sem SSL, também podendo ser 6667). Este é um canal IRC análogo à lista Debian Mentors.
• Lista Debian Devel Portuguese, para quem quiser suporte em português.
• Também há o canal #debian-devel-br, no mesmo IRC citado anteriormente.

Enviei um pacote para o Debian. Eu sou DM? Como ser DD?

Não, você não é um DM (Debian Maintainer).

Quem mantém pacotes no Debian é um mantenedor de pacotes ou empacotador. Existe uma classe, um pouco acima, que exige um pouco mais de experiência, chamada Debian Maintainer (DM). Para se tornar um DM, você precisará realizar alguns procedimentos básicos. Após algum tempo, você poderá fazer algumas provas de certificação, dentro do Debian, e se tornar um Debian Developer (DD).

Para entender tudo isso, assista a essa palestra, com 50 minutos de duração.

O meu pacote é inédito no Debian e foi para a NEW. Quanto tempo ficará lá?

A fila NEW é destinada a pacotes que estão nas seguintes situações:

• Entrando pela primeira vez no Debian. O pacote irá para essa fila mesmo tendo passado pelas mãos de um DD para upload.
• Retornando ao Debian depois de terem sido excluídos por qualquer motivo. Por curiosidade, aqui há uma lista de pacotes a serem removidos em breve.
• O pacote já estava no Debian mas, em virtude de um novo empacotamento (revisão Debian), ele agora gera um binário (.deb) a mais ou com nome diferente (um .deb foi renomeado).

Um pacote pode ficar de alguns minutos a 3 meses na NEW. O time FTP-Master não segue a ordem da fila. Como exemplo, considere que um deles chegue cansado do trabalho de noite mas tem como hobby analisar e aceitar pacotes. Só que o cansaço é tão grande quanto a vontade. Então, nesse caso, se for um analista que goste muito de Python, ele vai olhar pacotes que usem Python. É assim que funciona. O trabalho deles também é voluntário e é por isso que não seguem uma ordem. Assim sendo, pode ser que um determinado pacote seu pacote fique lá na fila 3 meses e um que você tenha enviado depois fique apenas 2 dias.

Ainda, se o pacote tiver problemas, ele não ficará na fila para sempre. Em determinado momento, ele será rejeitado. Se ele ainda não foi aprovado e nem rejeitado, é porque ainda não foi analisado.

Técnica de empacotamento

Quais modalidades de empacotamento estão disponíveis?

Há várias. Citando as mais comuns:

• Manutenção de pacotes: ocorre quando você introduz um pacote novo no Debian ou adota um que esteja órfão. Nesse caso o pacote passa a ser seu e você vira um mantenedor de pacote (que é diferente de Debian Maintainer ou DM).
• Trabalho de QA: é feito sobre pacotes que estão órfãos (sem um mantenedor atualmente). O objetivo é ajudar o pacote a evoluir, mesmo que ele não tenha um dono.
• NMU (Non-maintainer upload): trabalho feito sobre um pacote que tem um mantenedor que não está tendo tempo de cuidar do mesmo. Admite apenas alterações para sanar problemas críticos.
• Trabalho em times: nessa modalidade, você pode integrar um dos times de empacotamento no Debian e realizar trabalhos dentro do mesmo, com a supervisão e a ajuda de pessoas experientes no assunto.

Por onde começar a empacotar?

Para quem é iniciante, o ideal é começar por trabalhos de QA. Esse tipo de atividade não exige muito conhecimento e permite que sejam feitos apenas os ajustes que a pessoa conheça e domine. Com o tempo, cada um terá a habilidade de sanar todos os problemas e de passar para outras modalidades, como a de manutenção de pacotes.

Quais são os problemas mais comuns encontrados nos empacotamentos?

São vários. Os mais comuns para mim, quando atuando como sponsor são:

• Não registrar no arquivo debian/changelog todas as alterações feitas em um pacote.
• Não verificar com profundidade e paciência os dados de direitos autorais a serem inscritos no arquivo debian/copyright.

Esses são os problemas que mais ocorrem, dentre vários.

Como eu evito repetir problemas ou esquecer de algo em um pacote?

Simples! Crie um checklist!

Cada trabalho realizado em pacotes é um momento de aprendizado. Os seus sponsors, certamente, irão ensinar muito sobre empacotamento. Assim, a cada novo aprendizado, acresça itens no seu checklist básico.

O meu checklist básico como sponsor (e empacotador) está aqui.

Teria como eu saber qual versão de um programa está empacotado em outras distribuições, como Fedora?

Hum... Isso é interessante, pois você poderia, até mesmo, buscar patches feitos por outros mantenedores em outras distros.

Há um site muito interessante onde você poderá ver isso: https://repology.org/

Listas de discussão para aprendizagem e apoio

Em quais listas de discussão ou notícias eu deveria me cadastrar?

As seguintes listas de discussão ou notícias são essenciais para quem trabalha com empacotamento no Debian:

• debian-announce - lista de notícias relevantes e de interesse geral sobre o Debian. Baixíssima circulação anual. Em inglês.
• debian-devel-announce - lista de notícias relevantes para mantenedores de pacotes e para pessoas com envolvimento mais profundo no Debian. Baixíssima circulação anual. Em inglês.
• debian-infrastructure-announce - lista de notícias relevantes sobre a infraestrutura do Debian. Muito usada para comunicar quando servidores específicos ficarão temporariamente fora do ar. Baixíssima circulação anual. Em inglês.
• debian-legal - lista para discussões sobre o licenciamento de software no Debian. Extremamente interessante. Um ótimo lugar para aprender sobre licenciamento. Média circulação mensal. Em inglês.
• debian-mentors - lista voltada para a retirada de dúvidas sobre empacotamento no Debian. Alta circulação mensal. Em inglês.
• debian-devel-portuguese - lista nacional voltada para a retirada de dúvidas sobre empacotamento no Debian. Alta circulação mensal. Em português.
• debian-br-eventos - lista nacional para o anúncio de eventos Debian no Brasil. Baixíssima circulação anual. Em inglês.

Existem outras listas de discussão do Debian?

Sim, existem. Caso você tenha interesses mais específicos, consulte todas as listas Debian em http://lists.debian.org.

Chaves GPG

Por que eu deveria ter uma chave GPG assinada por DDs?

Inicialmente, você vai precisar de uma chave chave GPG para enviar pacotes para o repositório mentors.debian.org. Para fazer isso, essa chave não precisará da assinatura de DDs.

Se, um dia, você quiser se submeter ao processo para ser um DM ou um DD, precisará de ter uma chave RSA 4096 bits assinada por 2 DDs. Essa mesma chave será usada para você enviar os seus pacotes para o Debian, quando você já for um DM ou um DD. (neste mesmo FAQ eu já falei sobre o que vem a ser DM e DD e sobre o processo para se tornar um deles)

Eu quero criar uma chave. Como faço?

Como já foi dito anteriormente neste FAQ, siga as instruções existentes em https://wiki.debian.org/Keysigning. Siga os passos 1 a 7 COM ATENÇÃO. Lembro que a chave tem que ser do tipo RSA 4096 bits.

Eu quero assinar a chave de alguém. Como faço?

Inicialmente, você deve seguir algumas regras básicas. São elas:

• Estar frente a frente com a pessoa que precisa da assinatura.
• Mesmo que a conheça, solicitar um documento oficial com foto, como cédula de identidade ou carteira de motorista. Se for um estrangeiro, o documento deverá ser o seu passaporte.
• Obter os dados básicos da chave da pessoa. São eles: nome completo, endereço de email e fingerprint da chave. Isso poderá ser fornecido, pela pessoa, a partir do seguinte comando:

$ gpg --fingerprint <nr da chave>

• Conferir a foto e o rosto da pessoa.
• Conferir o nome no documento e nos dados de chave fornecidos.
• Levar consigo os dados referentes ao nome completo, endereço de email e fingerprint da chave. Há várias formas de fazer isso. Algumas:
  • Se a pessoa estiver com o seu notebook, pedir que ela emita o comando $ gpg --fingerprint <nr da chave>. A seguir, fotografe, com o seu telefone celular, a tela.
  • A pessoa também poderá entregar os dados por escrito (à mão).
  • Se a pessoa tiver um cartão de visitas com nome e email, ela poderá adicionar o fingerprint da chave no rodapé do cartão. Para ver exemplos, busque nas imagens do Google por "business card gnupg".
  • A pessoa poderá instalar o pacote signing-party e usar o comando gpg-key2ps para gerar "tirinhas" com os dados necessários. O resultado será um postscript que poderá ser impresso por programas como evince e okular. Exemplo:

$ gpg-key2ps -1 <nr da chave>   > tirinha.ps
$ evince tirinha.ps

• Depois de conferir o documento e os dados da chave da pessoa, leve tais dados de chaves para casa e assine a chave.
• A pessoa que desejar a assinatura tem que ter enviado a chave para repositórios públicos com o comando:

$ gpg --send-key <nr da chave>

Para assinar a chave da pessoa, utilize o comando caff. Veja um tutorial simples sobre isso em http://bit.ly/caffexim

Onde consigo mais informações sobre chaves GPG e assinatura?

Há diversos lugares que podem fornecer mais dados e curiosidades sobre chaves GPG. Nem todos estão atualizados, mas aqui estão alguns:

• http://bit.ly/GNUPG
• http://tiny.cc/festa_gpg
• https://www.debian.org/events/keysigning ou https://www.debian.org/events/keysigning.pt.html (em português)
• https://wiki.debian.org/GnuPG

How to's

Como empacotar algo inédito no Debian? (ITP)

• Você pode escolher um pacote inédito assim:
  • Opção 1: pesquisando na Internet em sites como GitHub, SourceForge etc. Escolha algo relevante e que não exista aos montes no Debian. Por exemplo, programas para encontrar arquivos dulpicados já existem, como rdfind, fdupes, duff, hardlink etc. Você pode empacotar algo similar a um pacote que já exista no Debian se ele tiver recursos interessantes e diferentes dos que já existem.
  • Opção 2: atendendo a uma solicitação de RFP (Request For Package) aqui.
  • Opção 3: procurando por um ITP (Intent To Package) antigo e, aparentemente, abandonado. Veja aqui.

• Na opção 1, você deverá escolher um programa, testá-lo, empacotá-lo para ver se consegue fazer isso e abir um bug ITP. Para abrir o ITP, use o comando $ reportbug. Quando ele perguntar o nome do pacote, digite wnpp.

• Na opção 2, você deverá escolher um programa, testá-lo e empacotá-lo para ver se consegue fazer isso. Depois, deverá se tornar dono do bug e renomear de RFP para ITP. Exemplo para o bug #316594:

Debian Bug report logs - #316594
RFP: opengl-doc -- OpenGL API documentation

• Você deverá enviar um email para control@bugs.debian.org, sem Subject, com o seguinte conteúdo:

retitle 316594 ITP: opengl-doc -- OpenGL API documentation
owner 316594 !

• ATENÇÃO: não use GMail ou outro webmail se emitir o comando retitle. Esses ambientes irão quebrar as linhas antes da coluna 80 e "bagunçar" o comando retitle. Sugiro instalar o Sylpheed (apt-get) e configurá-lo para usar o GMail (o Sylpheed já tem um template para isso) ou outro sistema de email que você queira.

• Para saber o que são os comandos de email anteriores, consulte este link.

• Na opção 3, veja se o ITP está sem atividade há muitos dias. Envie um email para o bug (<nr_do_bug>@bugs.debian.org), com o assunto 'Re: <título original>', perguntando se a pessoa ainda tem interesse em empacotar. Espere 10 dias. Caso não haja resposta, envie outra mensagem dizendo que vai esperar mais 5 dias pela resposta. Se não houver resposta, torne-se dono do bug e empacote. Você vai mandar um email para control@bugs.debian.org, sem Subject, com o seguinte conteúdo, considerando que o bug seja o #775096:

owner 775096 !

• EM TODOS OS CASOS ANTERIORES, utilize o comando $ apt-cache search <pacote> dentro da jaula-sid para saber se o pacote já não existe no Debian Unstable (às vezes já existe e não fecharam o bug ou abriram um para o que já existe).

• Também dê uma olhada na fila NEW, para ver se ele já não está lá.

• EM TODOS OS CASOS ANTERIORES, no debian/changelog, só terá a linha:

* Initial release. (Closes: #<nr_do_ITP>)

• Você não precisa citar cada alteração que fizer no empacotamento. Ao fazer upload, o seu pacote irá para a fila NEW, para ser inspecionado, manualmente, pela equipe FTP-Master, para entrar pela primeira vez no Debian. Um pacote poderá permanecer na fila NEW de 1 dia a 3 meses. A fila não é processada por ordem de chegada dos pacotes.

• Se você abrir um ITP e desistir de empacotar, renomeie-o para RFP e deixe-o sem dono. Exemplo para o bug 123456789:

retitle 123456789 RFP: abc -- nice letters in screen
noowner 123456789

• Você também pode buscar por pacotes que existam no Kali ou no Ubuntu e que não existam no Debian. Muito cuidado, pois essas distribuições possuem alguns pacotes que não são Software Livre. Se descobrir algo assim, por favor, adicione uma linha, em ordem alfabética, aqui. Para saber sobre pacotes que estão no Ubuntu e não estão no Debian, veja aqui.

• Caso você resolva empacotar algo que está no Kali ou no Debian, você poderá fazer isso do zero ou aproveitar o empacotamento já existente. Nos dois casos, você deverá abrir um ITP. No caso de aproveitar o empacotamento, mantenha o debian/changelog já existente e, no seu empacotamento, escreva:

* Initial release in Debian. (Closes: #<nr_do_ITP>)

• Depois disso, cite todas as alterações feitas por você.

Como adotar um pacote órfão? (ITA)

• Escolha um pacote órfão.

• Declare ao mundo que irá adotá-lo. Uma vez que o pacote já está no Debian, você enviará um ITA (Intent to Adopt). O procedimento está aqui. Basicamente, você tem que enviar um e-mail para control@bugs.debian.org, sem assunto, com alguns comandos no corpo. Veja um exemplo:

retitle 625952 ITA: maximus -- Automaximizing window management tool
owner 625952 !

• ATENÇÃO: não use GMail ou outro webmail se emitir o comando retitle. Esses ambientes irão quebrar as linhas antes da coluna 80 e "bagunçar" o comando retitle. Sugiro instalar o Sylpheed (apt-get) e configurá-lo para usar o GMail (o Sylpheed já tem um template para isso) ou outro sistema de email que você queira.

• Para saber o que foi feito nos comandos de email anteriores, consulte este link.

• No changelog do pacote, coloque na primeira linha:

* New maintainer. (Closes: #625952)

Como atender a um RFP?

O RFP (Request For Package) é um procedimento adotado por uma pessoa que não sabe empacotar ou que está sem tempo para isso. Utilizando a ferramenta reportbug, tal pessoa abre um bug contra o pseudo pacote wnpp, solicitando que algo seja empacotado.

Para atender a um pedido de empacotamento, siga as instruções abaixo.

• Escolha um pacote nesta relação ou aqui.

• Declare ao mundo que irá empacotá-lo. Você transformará o RFP em ITP (Intent to Package). O procedimento está aqui. Basicamente, você tem que enviar um e-mail para control@bugs.debian.org, sem assunto, com alguns comandos no corpo. Veja um exemplo:

retitle 119911 ITP: alephone -- marathon engine for related data games
owner 119911 !

• ATENÇÃO: não use GMail ou outro webmail se emitir o comando retitle. Esses ambientes irão quebrar as linhas antes da coluna 80 e "bagunçar" o comando retitle. Sugiro instalar o Sylpheed (apt-get) e configurá-lo para usar o GMail (o Sylpheed já tem um template para isso) ou outro sistema de email que você queira.

• Para saber o que foi feito nos comandos de email anteriores, consulte este link.

• No changelog do pacote, coloque na primeira linha:

* Initial release. (Closes: #<nr_do_ITP>)

• É importante ressaltar que o seu pacote irá para a fila NEW.

Como fazer um NMU?

O Non-maintainer upload (NMU) é feito quando o pacote já tem um mantenedor mas ele não está cuidando do mesmo por algum motivo (sem tempo, hospitalizado, viagem longa etc.). É feito com:

# dch --nmu

Algumas recomendações:

• Só se faz NMU caso realmente seja necessário. Geralmente, fazemos NMU em cima de um bug importante, serious ou grave, considerando que o mantenedor não tenha tomado providências a tempo ou caso o pacote tenha um mantenedor mas esteja nitidamente abandonado. Veja mais detalhes aqui.

• No NMU você pode fazer isso:
  • Fechar o bug que foi base para o NMU. Geralmente são bugs RC (Release Critical, que impedem o pacote de subir para o testing e ser lançado).
  • Fechar algum outro bug mais importante.
  • Atualizar o Standards-Version.
  • Atualizar o DH level.
  • Adicionar a variável ${misc:Depends}
  • Adicionar o campo Homepage.
  • Atualizar/adicionar o debian/watch, se não estiver funcionando. Se estiver funcionando mas for feio, não se mexe. Também não é o caso de usar o fake watch que eu inventei no pacote de outras pessoas.
  • Em casos extremos e considerando que o pacote esteja abandonado mesmo, pode-se migrar o debian/rules para o formato reduzido. Mas só se isso for essencial para o pacote funcionar.

• No fim, um monte de lintians ficarão sem solução. É assim que tem que ser, pois você não pode sair mexendo em tudo.

• O upload do NMU deve ser com atraso, como visto aqui. O upload poderá ser feito com até 15 dias de atraso. Isso será feito pelo seu sponsor (comando dput -e 15 pacote.changes).

• Depois do upload (o sponsor avisará sobre isso), você deverá citar no bug que fez o NMU, colocando uma cópia do changelog e anexando um debdiff (debdiff entre o .dsc antigo e o novo). Veja um exemplo aqui. Alternativamente, você pode usar o comando nmudiff, dentro do diretório do upstream no pacote, para gerar a mensagem de NMU. Evite criar um novo bug para tal mensagem; use o bug RC já aberto, sempre que possível.

• É possível fazer um NMU mais agressivo, mexendo em mais coisas, caso o mantenedor permita LowNMU. Também é possível fazer uma atualização completa do pacote, incluindo um "new upstream version", caso o pacote esteja realmente abandonado. Nesse caso, sugiro um upload com 15 dias de atraso, além da abertura de um novo bug declarando que está sendo feito um NMU completo.

Onde encontrar possibilidades de NMU?

Para procurar por bugs RC, acesse:

• https://bugs.debian.org/release-critical/debian/all.html

Há também esse link:

• https://people.debian.org/~eriberto/help_a_package.html

Neste último, veja as colunas RC e o item "Top 200 sources in Debian Sid with RC BUGs".

Para ver os RC que você tem em pacotes instalados no seu Sid, use o comando:

# rc-alert

Antes de trabalhar no bug, olhe se não há nada sobre ele na fila de upload com atraso:

• https://ftp-master.debian.org/deferred.htm

Se quiser fazer o download de algo que está na fila, use:

• https://ftp-master.debian.org/deferred

Como fazer um pacote para Backports?

Backports é um repositório que contém pacotes inéditos ou mais novos para stable. Esses pacotes são oriundos do testing. Essa técnica permite trazer pacotes mais novos do testing para o stable, sem fazer muitas alterações no stable, pois o referido pacote será reconstruído em uma jaula stable, usando as dependências do stable. Então, o seu stable não será inundado por libraries e dependências oriundas do testing ao instalar o pacote desejado (feito para Backports).

Para construir um pacote para Backports faça o seguinte:

• Crie uma jaula stable.
• Acesse https://backports.debian.org/ e leia o conteúdo dos links Instructions e Contribute MAS não faça nada ainda. Apenas entenda.
• Na jaula stable, em /etc/apt/sources.list, adicione uma nova entrada deb-src apontando para o testing e uma outra deb apontando para o Backports. Exemplo, considerando "Buster" como atual stable:

deb http://ftp.br.debian.org/debian buster main
deb http://ftp.br.debian.org/debian buster-backports main
deb-src http://ftp.br.debian.org/debian testing main

• Execute apt-get update e apt-get upgrade.
• Busque o pacote desejado no testing com apt-get source.
• Dentro do pacote execute dch --bpo. Usando o Debian 10 Buster como exemplo, o debian/changelog deverá ficar assim:

netdiscover (0.5.1-3~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.

 -- Joao Eriberto Mota Filho <eriberto@debian.org>  Mon, 05 Aug 2019 08:57:18 -0300

• Execute debuild. Em princípio o seu pacote Backports está pronto, pois tal pacote deverá estar o mais próximo possível do que veio do testing.
• Só faça alterações caso isso seja necessário para que o pacote possa ser construído e instalado. Em 99% dos casos não será necessário alterar nada.
• Ignore TODOS os lintians.
• Caso seja necessário utilizar uma versão mais nova de algum pacote para construir, verifique se o mesmo já não está presente no Backports. Por exemplo: o Debian Buster (stable atual quando este how to foi escrito) usa o DebHelper 12. Caso seja lançado o DebHelper 13 e você tenha no debian/control do pacote oriundo do testing um campo Build-Depends: debhelper-compat (= 13), não o altere para 12 sem antes verificar se a versão 13 já não está no Backports (use apt-get install -t buster-backports debhelper).
• Caso você use controle de versão para o empacotamento e o servidor Salsa, trabalhe em uma branch backports. Não faça commits de backports na branch debian/master, que é dedicada ao unstable. Mesmo que você use controle de versão, para o Backports isso é opcional.
• Teste o pacote, instalando-o no seu stable.
• Finalmente, só faça Backports para os seus pacotes, para pacotes órfãos ou para pacotes de outros mantenedores que autorizarem isso. Para este último caso, se for necessário, você pode fazer um upload com atraso de 10 dias e abrir um bug declarando isso, nos mesmos moldes de um NMU.
• Se o pacote estiver entrando no Backports pela primeira vez, ele irá para a fila NEW do Backports. Esse ciclo será renovado para cada stable que for lançado. Exemplo: você envia o pacote X para o Backports do atual stable. X irá para a Backports NEW. Os próximos uploads do X para o Backports serão aceitos automaticamente, sem passar pela NEW. Ao ser lançado um novo stable, o pacote X, se enviado para o Backports, irá para a fila NEW novamente.

Como fazer um repositório .deb pessoal ou dentro da minha empresa?

Há duas formas de se fazer isso: a forma fácil e a melhor forma. A forma fácil é usando os comandos dpkg-scanpackages e dpkg-scansources. Procure sobre isso na Internet. Já a melhor forma é usando o mesmo mecanismo que o Debian usa, que é baseado no pacote reprepro. Sugiro que você consulte o seguinte link para saber mais sobre com fazer isso: https://www.digitalocean.com/community/tutorials/how-to-use-reprepro-for-a-secure-package-repository-on-ubuntu-14-04

Atualização: há um terceiro método que parece ser muito bom (mas eu nunca usei). Pesquise por mini-dinstall.