Existe uma maneira fácil de corrigir automaticamente as fontes do ubuntu à medida que elas se tornam disponíveis e carregam em um PPA?

Estou procurando uma ferramenta para fazer o seguinte:

• Detectar automaticamente atualizações para um conjunto de pacotes de origem (especificamente gtk + 2 e gtk + 3)
• faça o download do pacote de origem
• aplicar meus próprios patches personalizados à fonte
• confirmar o patch corretamente ( dpkg-source --commit [something-or-other]?)
• se for bem-sucedido, faça o upload para um PPA no Launchpad (para o qual eu posso apontar meu sistema da maneira usual).

O Launchpad pode fazer tudo isso por mim?

Caso contrário, existe uma ferramenta que fará tudo isso automaticamente em um trabalho cron?

Falhando no exposto, eu mesmo bato em alguma coisa, mas quais comandos eu preciso:

• detectar e baixar as atualizações do pacote de origem? (Eu preferiria algo como (bzr | git) pull em vez de precisar obter uma nova cópia de cada vez)
• confirmar automaticamente o patch localmente (eu usaria a mesma descrição de confirmação toda vez)?
• carregar as fontes de maneira não interativa para um PPA?

Encontrei uma pergunta ( qual é a maneira correta de corrigir o Wine para um PPA personalizado? ), Que é semelhante, mas as etapas da resposta ainda são basicamente manuais e interativas. Uma versão completamente prática e a detecção automática de atualizações de fontes ajudariam muito.

Bem, parece que as receitas de embalagens são o caminho a percorrer aqui. Basicamente, as receitas de empacotamento podem criar automaticamente pacotes de código-fonte do Ubuntu e enviá-los para um PPA sempre que uma ramificação bzr na barra de ativação for alterada. A documentação on-line é muito boa, mas vou dar alguns exemplos ...

Primeiro, você especifica um ramo a ser rastreado (por exemplo lp:gtk3) e depois adiciona um comando para aninhar seu próprio ramo de empacotamento Debian nesse ramo. Veja esta receita que criei para compilações diárias do Inkscape.

# bzr-builder format 0.4 deb-version 1:0.48+devel+{revno}+{revno:packaging}
lp:inkscape
nest packaging lp:~inkscape.dev/inkscape/debian-packaging debian

Esta receita cria um pacote Ubuntu todos os dias usando a fonte upstream mais recente do Inkscape, mas copia instruções personalizadas de empacotamento do Debian da lp:~inkscape.dev/inkscape/debian-packagingfilial para uma subpasta chamada " debian".

A página de receita da embalagem no Launchpad permite especificar em qual PPA os arquivos serão carregados automaticamente. No nosso caso, ele é carregado aqui .

Como uma abordagem alternativa, você pode basear sua receita em um pacote Ubuntu existente, em vez de diretamente na fonte upstream. Por exemplo lp:ubuntu/gtk+3.0,. Você precisaria criar uma ramificação desse código e confirmar as modificações necessárias. Vamos chamá-lo lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build, por exemplo. Você criaria uma receita para mesclar automaticamente suas alterações, em vez de aninhar as instruções de embalagem. A receita seria algo como:

# bzr-builder format 0.4 deb-version {debversion}+{date}
lp:ubuntu/gtk+3.0
merge my-custom-build lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build

Esta receita, portanto, cria automaticamente um pacote de origem personalizado do Ubuntu e o carrega no seu PPA sempre que houver uma alteração no pacote oficial do Ubuntu.

Se você seguir essa abordagem de "mesclagem", terá duas opções para aplicar seus patches. Você pode editar o código-fonte upstream diretamente em sua ramificação e deixar o bzr cuidar da mesclagem ou criar arquivos de correção dentro da debian/pasta usando quilt. Cada um tem suas próprias vantagens / desvantagens. A abordagem anterior é um pouco mais inteligente ... se um dos seus patches for adotado pelo desenvolvedor upstream, a mesclagem geralmente continuará funcionando e o pacote Ubuntu será compilado. A última abordagem permite que você lide com seus patches usando a abordagem padrão baseada no Debian de manter o código de empacotamento separado do código upstream ... no entanto, se o desenvolvedor upstream adotar um de seus patches, o quilt não poderá aplicar o (duplicado) patch e o pacote falhará na compilação.