Os pacotes binários do Debian na distribuição são gerados de pacotes fontes Debian, que estão num formato especial para ajudar na fácil e automática construção dos binários.
Houva uma versão anterior do formato fonte do Debian, que está agora acabando. As instruções para converter um pacote do velho estilo são dadas no manual de política do Debian.
Várias ferramentas são dispostas para manipulação de pacotes fonte; elas empacotam e desempacotam fontes, ajudam a construir os pacotes binários e ajudam a manejar a distribuição de novas versões.
Eles são introduzidos e usos típicos são descritos aqui; veja
dpkg-source(1) para documentação completa sobre seus argumentos e
operação.
Para exemplos de como construir um pacote fonte do Debian e como usar essas
ferramentas que são usadas pelos pacotes fonte do Debian, por favor veja o
pacote exemplo hello.
dpkg-source - empacota e desenpacota pacotes código do Debian
Esse programa é freqüentemente usado manualmente e é também chamado por scripts
de construção automática independentes de pacote como o
dpkg-buildpackage.
Para desempacotar um pacote é tipicamente chamado com
dpkg-source -x .../cominho/para/nomedoarquivo.dsc
com o nomedoarquivo.tar.gz e nomedoarquivo.diff.gz (se aplicável) no mesmo diretório. Ele desempacota em pacote-versão, e se aplicável pacote-versão.orig, no diretório corrente.
Para criar um pacote fonte é normalmente chamado:
dpkg-source -b pacote-versão
Isso irá criar o .dsc, .tar.gz e
.diff.gz (se apropriado) no diretório atual.
dpkg-source não limpa a árvore de fontes primeiro - isso precisa
ser feito separadamente se requerido.
Veja também Pacotes fonte como arquivos, Seção 3.3.
dpkg-buildpackage - script de controle de criação de pacote.
dpkg-buildpackage é um script que chama o
dpkg-source, odebian/rules alvos clean,
build e binary, dpkg-genchanges e
pgp para construir um fonte assinado e um pacote binário para
envio.
Ele é usualmente chamdo manualmente do topo da árvore de diretórios do fonte, construído ou não. Ele pode ser chamado sem argumentos; argumentos úteis incluem:
PATH. commando-pgp deve se comportar como o
pgp.
PATH se necessário, e passar seus outros argumentos para o comando
que ele chamar. Se não houver comando-root na linha de comando,
então o dpkg-buildpackage não irá fazer nada para ganhar privilégio
root, então para a maior parte dos pacotes, ele deverá ser chamado como root
para iniciar.
dpkg-source(1).
dpkg-gencontrol - geera arquivos de controle de pacote binário
Esse programa é usualmente chamado do debian/rules (veja A árvore fonte Debianisada, Seção 3.2) no topo da árvore de diretórios do fonte.
Esse é usualmente feito antes dos arquivos e diretórios na arvoré de diretórios
temporária onde o pacote está sendo construído tem suas permissões e são
configurados seus donos e o pacote é construído usando o dpkg-deb
dpkg-deb/ [5].
dpkg-gencontrol precisa ser chamado depois de todos os arquivos
que irão estar no pacote terem sido colocados no diretório de construção
temporário, para que o cálculo do tamanho do pacote instalado seja correto.
É também necessário que o dpkg-gencontrol seja rodado depois do
dpkg-shlibdeps para que as substituições de variáveis criadas pelo
dpkg-shlibdeps em debian/substvars estejam
disponíveis.
Para um pacote que gera apenas um pacote binário e que constrói em
debian/tmp relativo ao topo do pacote fonte, é geralmente
suficiente chamar o dpkg-gencontrol.
Fontes que controem vários binários tipicamente precisarão de algo como:
dpkg-gencontrol -Pdebian/tmp-pct -ppacote
O -P diz ao dpkg-gencontrol que o pacote está sendo
construído em um diretório não padrão, e o -p diz qual arquivo de
controle do pacote devem ser gerados.
dpkg-gencontrol também adiciona informação à lista de arquivos em
debian/files, para benefício de por exemplo, uma futura chamada ao
dpkg-genchanges.
dpkg-shlibdeps - calcula dependências de bibliotecas compartilhadas
Esse programa é usalmanete chamado de debian/rules antes do
dpkg-gencontrol (veja A
árvore fonte Debianisada, Seção 3.2), no topo da árvore de diretórios do
fonte.
Seus argumentos são executáveis. [6] para o qual as dependências de bibliotecas compartilhadas devem ser incluídas no arquivo de controle do pacote binário.
Se algumas das bibliotecas compartilhadas encontradas devem apenas garantir um Recommends ou Suggests, ou se algumas garantem uma Pre-Depends, isso pode ser conseguido usando a opção -dcampo-de-dependência antes daqueles executáveis. (Cada -d toma efeito até a próxima -d.)
dpkg-shlibdeps não causa diretamente a saída do arquivo de
controle a ser modificado. Ao contrário por padrão, ele adiciona ao arquivo
debian/substvars configurações de variáveis como
shlibs:Depends. Essas configurações de variáveis devem ser
referênciadas em campos de dependência nas seções por-pacote-binário
(per-binary-package) apropriadas do arquivo de controle do fonte.
Por exemplo, o pacote procps gera dois tipos de binários, binários
C simples como ps que requer uma pré-dependência e binários de
tela cheia ncurses como o top que requer apenas uma recomendação.
Ele pode dizer em seu debian/rules:
dpkg-shlibdeps -dPre-Depends ps -dRecommends top
e então no seu arquivo de controle principal debian/control:
...
Package: procps
Pre-Depends: ${shlibs:Pre-Depends}
Recommends: ${shlibs:Recommends}
...
Fontes que produzem muitos pacotes binários com requerimentos de dependência de
bibliotecas compartilhadas podem usar a opção
-pnomedoprefixo para sobrescrever o prefixo
shlib: padrão (uma chamada de dpkg-shlibdeps por
configuração dessa opção). Eles podem então produzor vários conjuntos de
variáveis de dependência, cada um na forma
nomedoprefixo:campodedependência, que podem
ser referidos nas partes apropriadas dos arquivos de controle do pacote
binário.
dpkg-distaddfile - adiciona arquivos ao debian/files
Alguns envios de pacotes precisam incluir arquivos diferentes dos arquivos dos pacotes binário e de fonte.
dpkg-distaddfile adiciona um arquivo ao debian/files
para que seja incluído no arquivo .changes quando o
dpkg-genchanges for rodado.
Ele é normalmente chamado do alvo binário do
debian/rules:
dpkg-distaddfile nomedoarquivo seção prioridade
O nomedoarquivo é relativo ao diretório onde
dpkg-genchanges irá esperar encontrá-lo - ele é normalmente o
diretório acima do diretório topo da árvore de código fonte. O alvo do
debian/rules deve por o arquivo lá antes de chamar o
dpkg-distaddfile.
O seção e o prioridade são passados intocados no arquivo .changes resultante. Veja Section e Priority, Seção 4.2.9.
dpkg-genchanges - gera um arquivo .changesde controle de upload
Esse programa é usalmente chamado por scripts de construção automática
pacote-independente como o dpkg-buildpackage, mas deve ser chamado
manualmente.
É chamado normalmente no level topo da árvore de construção de código e quando chamado sem argumentos imprime um arquivo .changes baseado na informação que está nos arquivos changelog e control do pacote fonte e os pacotes fonte que deveriam ter sido construídos.
dpkg-parsechangelog - produz representação analisada de um changelog
Esse programa é usado internamente pelo dpkg-source. Ele pode
também ser as vezes útil no debian/rules e algum outro lugar. Ele
analisa um changelog, debian/changelog por padrão e imprime uma
representação no formato de arquivo de controle da informação nele para a saída
padrão.
dpkg-architecture - informação sobre o sistema host e construtor
Esse programa pode ser usado manualmente, mas também é chamado pelo dpkg-buildpackage ou debian/rules para configurar o ambiente ou fazer variáveis que especificam a arquitetura host e construtora para o processo de construição do pacote.
O esquema de arquivo fonte descrito depois é para permitir uma árvore fonte Debianisada com algumas informações de controle associadas para ser reproduzido e transportado facilmente. A árvore fonte Debianisada é uma versão do programa original com certos arquivos adicionados para o benefício do processo de Debianisação e com outras mudanças requeridas feitas ao resto do código fonte do programa e aos scripts de instalação.
Os arquivos extras criador pelo Debian estão no subdiretório debian do diretório topo da árvore fonte Debianisada. Eles são descritos abaixo.
Esse arquivo é um makefile executável e contém as entradas especificas do programa pra compilar o pacote e constuir o(s) pacote(s) binários do código.
Ele deve começar com a linha #!/usr/bin/make -f, para que ele
possa ser chamado pelo seu nome ao invés de chamar-se o make
explicitamente.
Já que um script debian/rules interativo torna impossível
autocompilar aquele pacote e torna também difícil a reprodução do mesmo pacote
binário por outras pessoas, todos os alvos requeridos devem
ser não interativos. No mínimo, os alvos requeridos são os chamado pelo
dpkg-buildpackage, nomeados, clean, binary,
binary-arch e build. Também segue que qualquer alvo do qual
dependam esses alvos devemser não intereativos.
Os alvos com presença requerida são:
Para alguns pacote, notávelmente aqueles em que a mesma árvore de diretório é
compilada de diferentes maneiras para produzir dois pacotes binários, o alvo
build não faz muito sentido. Para esses pacotes é bom o bastante
prover dois (ou mais) alvos (build-a e build-b ou o
que for) para cada uma das maneiras de se compilar o pacote e um alvo
build que não faz nada. O alvo binaryterá de
construir o pacote em cada uma das maneiras possíveis e fazer o pacote binário
de cada um.
O alvo build não deve fazer nada que possa requerer privilégios
root.
O alvo build pode precisar rodar clena antes - veja
abaixo.
Quando um pacote tem uma rotina de configuração que leva um longo tempo, ou
quando os makefiles são desenhados pobremente, ou quando build
precisa rodar clean antes, é uma boa idéia fazer touch
build quando o processo de construção estiver completo. Isso irá
assegurar que se debian/rules build for rodado novamente ele não
irá reconstruir o programa todo.
binary deve ser tudo que é necessário ao usuário para
construir o pacote binário. Todos esses alvos devem ser não interativos. Ele
é dividido em duas partes: binary-arch constrói os arquivos de
saída do pacote que são específicos de uma arquitetura particular e
binary-indep constrói aqueles que não são.
binary deve normalmente ser um alvo sem comandos que simplesmente
depende do binary-arch e do binary-indep.
Ambos os alvos binary-* devem depender do alvo build,
acima, para que o pacote seja construído se não foi ainda. Ele deve entào
criar o(s) pacote(s) binário(s) relevante(s), usando o
dpkg-gencontrol para fazer seus arquivos de controle e
dpkg-deb para construí-los e colocá-los no diretório pai do
diretório topo do fonte.
Se nenhum dos alvos binary-* tem algo para fazer (isso irá sempre
ser o caso, se o fonte gerar apenas um único pacote binário, dependente de
arquitetura ou não) ele deve ainda existir, mas deve sempre ter
sucesso.
Pacotes Binários, Capítulo 2 descreve como construir pacotes binários.
O alvo binary deve ser chamado como root.
build e
binary podem ter tido, exceto que ele deve deixar qualquer arquivo
de saída criado no diretório pai pela execução do binary. Esse
alvo deve ser não interativo.
Se um arquivo build foi passado pelo touch no fim do
build, como sugerido acima, ele deve ser removido como a primeira
coisa que o clean faz para que rodar build de novo
depois de um clean interrompido não o faça pensar que tudo já foi
feito.
O alvo clean deve ser chamado como root se binary foi
chamado desde o último clean clean ter sido chamado como root (já
que o build pode criar diretórios por exemplo).
Esse alvo deve ser chamado em qualquer diretório e deve tomar cuidade de limpar qualquer arquivo temporário que possa deixar.
Esse alvo é opcional, mas provê-lo se possível é possivelmente uma boa idéia.
Os alvos build, binary e clean devem ser
chamados dentro do diretório atual do diretório principal do pacote.
Alvos adicionais podem existir em debian/rules, ou publicados ou interfaces não documentadas ou para o uso interno do pacote.
A arquitetura para que nós construímos é determinada pelas variáveis make via
dpkg-architecture (veja dpkg-architecture - informação
sobre o sistema host e construtor, Seção 3.1.8). Você pode pegar a
arquitetura Debian e a string de especificação de arquitetura estilo GNU para a
máquina de construção tanto quanto a máquina host. Aqui está a lista de
variáveis make:
onde * é ou BUILD para especificação da máquina de construção ou HOST para especificação da máquina para a qual construímos.
Compatibilidade anterior pode ser provida no arquivo rules configurando as variáveis necessárias para valores padrão encaixáveis, por favor se refira à documentação do dpkg-architecture para detalhes.
É importante entender que a string DEB_*_ARCH faz apenas determinar para qual arquitetura Debian nós construímos. Ela não deve ser usada para conseguir informações do sistema ou da CPU, as variáveis do estilo GNU deve ser usado para isso.
Esse arquivo contém detalhes independentes de versão sobre o pacote fonte e sobre o pacote binário que cria.
Ele é uma série de conjuntos de campos de controle, cada um sintaticamente similar a um arquivo de controle de pacote binário. Os conjuntos são separados por uma ou mais linhas em branco. O primeiro conjunto é de informações sobre o pacote fonte em geral; cada conjunto subsequente descreve um pacote binário que a árvore fonte constrói.
A sintática e a semântica dos campos são descritas abaixo em Arquivos de controle e seus campos, Capítulo 4.
Os campos (independentes de pacote binário) gerais são:
Os campos por pacote binário são:
Esses campos são usados pelo dpkg-gencontrol para gerar arquivos
de controle para pacotes binário (veja abaixo), pelo
dpkg-genchanges para gerar o arquivo .changes para
acompanhar o upload, e pelo dpkg-source quando ele cria o arquivo
de controle fonte .dsc como parte de um arquivo fonte.
Os campos aqui podem conter referências a variáveis - seus valores irão ser
substituídos pelo dpkg-gencontrol, dpkg-genchanges ou
dpkg-source quando eles geram arquivos de controle de saída. Veja
debian/substvars e
substituições de variáveis, Seção 3.2.4 para detalhes.
Campos adicionais adicionados pelo usuário podem ser adicionados ao arquivo de controle do pacote fonte. Esses campos irão ser ignorados e não copiados aos (por exemplo) arquivos de controle do pacote binário ou fonte ou arquivos de controle de upload.
Se você deseja adicionar campos não suportados adicionais a esses arquivos de saída você deve usar o mecanismo descrito aqui.
Campos no arquivo de informações de controle fonte principal com nomes começando com X seguido de uma ou mais letras BCS e um hífen - serão copiados aos arquivos de saída. Só a parte do nome do campo depois do hífen será usado no arquivo de saída. Onde a letra B é usada o campo aparecerá nos arquivos de controle do pacote binário, onde a letra S é usada nos arquivo de controle do pacote fonte e onde C é usado nos arquivos de controle (.changes) de upload.
Por exemplo, se o arquivo de controle de informação de fonte principal contém o campo
XBS-Comment: Eu fico entre a vela e a estrela.
então os arquivos de controle dos pacotes binário e fonte conterão o campo
Comment: Eu fico entre a vela e a estrela.
Esse arquivo grava as mudanças específicas do Debian do pacote. [7].
Ele tem um formato especial que permite às ferremantas de construção de pacote descobrirem qual versão do pacote está sendo construída e descobrir outras informações específicas de lançamento.
O formato é uma série de entradas como essa::
pacote (versão) distribuição(ões); urgency=urgência
* detalhes de mudanças
mais detalhes de mudanças
* ainda mais detalhes de mudanças
-- nome do mantenedor e endereço de e-mail data
pacote e versão são a fonte do nome do pacote e número de versão.
distribuição(ões) lista as distribuições nas quais essa versão deve ser instalado quando for enviada - ela é copiada para o campo Distribution no arquivo .changes. Veja Distribution, Seção 4.2.14.
urgência é o valor do campo Urgency no arquivo
.changes para o envio. Veja Urgency, Seção
4.2.15. Não é possível especificar uma urgência contendo vírgulas;
vírgulas sào usadas para separar configurações
palavra-chave=valor no formato changelog do
dpkg (apesar de haer atualmente apenas uma única
palavra-chave útil, urgency).
Os detalhes de mudança podem de fato ser uma série de linhas começando com pelo menos dois espaços, mas convencionalmente cada mudança começa com um asterisco e um espaço separatório e a continuação das linhas são indentados para alinhá-las com o início do texto acima. Linhas em branco podem ser usadas para separar grupos de mudanças, se desejado.
O nome e endereço de e-mail do mantenedor não devem necessáriamente ser aqueles do mantenedor do pacote usual. Eles devem ter detalhes da pessoa que fez essa versão. A informação aqui será copiada para o arquivo .changes e depois usada para enviar uma resposta quando o envio for feito.
A data deve ser no formato RFC822 [8]; deve incluir a zona de tempo especificada numericamente, com o nome dela ou abreviação opcionalmente presente como comentário.
A primeira linha 'título' com o nome do pacote deve começar na margem da esquerda, a linha `trailer' com os detalhes do mantenedor e da data devem ser precedidos por exatamente um espaço. Os detalhes do mantenedor e a data devem ser separadas por, exatamente, dois espaços.
Um modo de Emacs para editar esse formato está disponível ele é chamado debian-changelog-mode. Você pode tê-lo selecionado automaticamente quando você edita um changelog Debian adicionando uma cláusula de variáveis locais ao fim do changelog.
É possível usar um formato diferente do padrão provendo É um analisador para o formato que você quer usar.
Para que o dpkg-parsechangelog rode seu analisador você deve incluir uma linha dentre as 40 últimas do seu arquivo identificando a expressão regular de perl: \schangelog-format:\s+([0-9a-z]+)\W A parte em parenteses deve ser o nome do formato. Por exemplo, você pode colcoar:
@@@ changelog-format: joebloggs @@@
Nomes de formatos de Changelog são strings não vazias de alfan-uméricos.
Se tal linha existir então o dpkg-parsechangelog procurará pelo analisador como /usr/lib/dpkg/parsechangelog/nome-do-formato ou /usr/local/lib/dpkg/parsechangelog/nome-do-formato; é um erro não encontrá-lo ali ou não ser um executável. O formato de changelog padrão é o dpkg e um analisador é provido com o pacote dpkg.
O analisador será chamado com o changelog aberto na entrada padrão no início do arquivo. Ele deve ler o arquivo (deve procurar se deseja) para determinar as informações requeridas e retornar a informação analisada para a saída padrão no formato de uma série de campos de controle no formato padrão. Por padrão ele deve retornar informação apenas sobre a versão mais recente no changelog; ele deve aceitar uma opção -vversão para retornar mudanças de todas as versões presentes estritamente depois de versão e deve então ser um erro a versão não estar presente no changelog.
Os campos são:
Se várias versões estão sendo retornadas (por causa de uso do -v, o valor de urgency deve ser o do maior código de urgência listada no início de qualquer sas versões pedidas seguidas dos comentários (separados por espaços) concatenados de todas as versões pedidas; o mantenedor, versão, distribuição e data devem sempre ser da mais recente versão.
Para o formato do campo Changes veja Changes, Seção 4.2.18.
Se o formato do changelog que está sendo analisado sempre ou quase sempre deixa uma linha em branco entre as notas de mudanças individuais, essas linhas devem ser retiradas, para fazer o resultado de saída compacto.
Se o formato de changelog não contém data ou nome do pacote essa informação deve ser omitida da saída. O analisador não deve tentar sintetizá-la ou encontrá-la de outras fontes.
Se o changelog não tem o formato esperado o analisador deve sair com um estado de saída de não-zero, ao invés de tentar "dar um jeito" e possivelmente mostrar saída errada.
Um analisador de changelog não deve interagir com o usuário.
Quando dpkg-gencontrol, dpkg-genchanges e
dpkg-source gera arquivos de controle eles fazem substituições de
variáveis em sua saída logo antes de escrevê-la. Substituiçào de variável tem
sua forma ${nome-da-variável}. O arquivo opocional
debian/substvars contém substituições de variáveis a serem usadas;
variáveis podem também ser configuradas diretamente do
debian/rules usando a opção -V para os comandos de
empacotamento de fonte e certas veriáveis predefinidas estão a disposição.
Ele é normalmente gerado e modificado dinamicamente pelos alvos do
debian/rules; nesse caso ele deve ser removido pelo alvo
clean.
Veja dpkg-source(1) para detalhes mais completos sobre
substituição de variáveis do código, incluindo o formato do
debian/substvars.
Esse arquivo não é uma parte permanente da árvore fonte; ele é usado enquanto
construindo pacotes para gravar quais arquivos estão sendo gerados.
dpkg-genchanges o usa quando gera um arquivo
.changes.
Ele não deve existir em um pacote fonte lançado e então ele (e qualquer outro
arquio de backup ou arquivo temporário como files.new [9]) deve ser removido pelo alvo
clean Ele deve também ser sábio para garantir um início fresco
esvaziando ou removendo-o no início do alvo binary.
dpkg-gencontrol adiciona uma entrada para esse arquivo para o
arquivo .deb que será criado pelo dpkg-deb do arquivo
de controle que ele gera para que para a maioria dos pacote tudo o que precise
ser feito com esse arquivo é deletado no clean.
Se o upload de um pacote inclui arquivos que não o pacote fonte e qualquer
pacote binário os quais os arquivos de controle foram feitos com
dpkg-gencontrol então eles devem ser colocados no diretório pai do
diretório principal do pacote e dpkg-distaddfile deve ser chamado
para adicionar o arquivo à lista em debian/files.
Esse é a localização temporária canônica para a construção dos pacotes binários
pelo alvo binary. O diretório tmp serve como o raiz
da árvore do sistema de arquivos porque ele está sendo construído (por exemplo,
usando os alvos install dos makefiles do pacote externo e redirecionando a
saída lá) e também contém o subdiretório DEBIAN. Veja Criando arquivos do pacote -
dpkg-deb, Seção 2.1.
Se vários pacotes binários são gerados da mesma árvore de fonte é usual usar vários diretórios debian/tmpalgo por exemplo tmp-a ou tmp-doc.
Quaisquer diretórios tmp criados e usados pelo binary
devem ser, claro, removidos pelo alvo clean.
Como existe no site FTP, um pacote fonte Debian consiste de três arquivlos relacionados. Você deve ter as versões certas de cada um para estar apto a usá-los.
O arquivo de controle do pacote fonte é gerado pelo dpkg-source
quando ele constrói o arquivo fonte, de outros arquivos no pacote fonte,
descrito acima. Quando desempacotando ele é checado com os arquivos e
diretórios nas outras partes do pacote fonte, como descrito abaixo.
tar
contendo o código fonte do programa do autor externo. O arquivo tar
desempacota num diretório
pacote-versão-externa.orig, e não contém
arquivos em lugar nenhum que nele ou seus subdiretórios.
Todos os diretórios no diff devem existir, exceto o diretório
debian do diretório principal da árvore do fonte, que será criado
pelo dpkg-source se necessário quando desempacotando.
O programa dpkg-source vai tornar o arquivo
debian/rules executável automaticamente (veja abaixo).
Se não há código fonte original - por exemplo, se o pacote for especialmente preparado para o Debian ou o mantenedor Debian é o mesmo mantenedor externo - o formato é um pouco diferente: então não há diff e o arquivo tar é chamdo pacote_versão.tar.gz e contém um diretório pacote-versão.
dpkg-source
dpkg-source é o método recomendado de desempacotar um pacote fonte Debian. No entanto, se não está disponível é possível desempacotar assim:
Não é possível gerar um arquivo fonte válido do Debian sem usar o
dpkg-source. Em particular, tentar usar o diff
diretamente para gerar o arquivo diff.gz não funcionará.
O pacote fonte não pode conter nenhum link duro (hard lynk) [10] [11], aparelhos, arquivos especiais, sockets ou arquivos setgid ou setuid. [12]
As ferramentas de empacotamento de fonte controlam as mudanças entre o pacote
original e o Debianisado usando o diff e o patch.
Mudar a árvore fonte original incluída no .orig.tar.gz para o
fonte Debianisado não deve involver nenhuma mudança que não possa ser
administradapor essas ferramentas. Mudanças problemáticas que causem a parada
do dpkg-source com um erro quando construindo o pacote fonte são:
Mudanças que causam a apresentação de um aviso mas permite ao
dpkg-source a continuar de qualquer modo são:
Mudanças que não são representadas, mas que não são detectadas pelo
dpkg-source, são:
O diretório debian e o debian/rules são manuseados
especialmente pelo dpkg-source - antes de aplicar as mudanças ele
cria o diretório debian e depois irá fazer o
debian/rules executável por qualquer usuário.
ijackson@gnu.ai.mit.edubweaver@debian.orgschwarz@debian.orgsrivasta@debian.orgJ.D.Gilbey@qmw.ac.ukdebian-policy@lists.debian.orgdockov@zaz.com.br