Peek: Adicionar Peek a um PPA

Criado em 31 ago. 2016  ·  32Comentários  ·  Fonte: phw/peek

Isso nos permitiria atualizar o Peek sem ter que baixar novamente seu deb installer a cada lançamento.

help wanted packaging

Comentários muito úteis

Ok, estamos chegando a algum lugar :) Finalmente comecei a fazer isso, agora há um PPA de compilação diária em:

https://code.launchpad.net/~peek-developers/+archive/ubuntu/daily

O código é construído usando esta receita: https://code.launchpad.net/~peek-developers/+recipe/peek-daily
As informações do pacote estão na verdade em um branch órfão no repositório principal Peek git, consulte https://github.com/phw/peek/tree/debian-packaging

Eu apreciaria se alguém pudesse ter um tear sobre isso e me dar algum feedback, já que faz muito tempo desde que brinquei com o pacote Debian e os PPAs do Launchpad, e a IU do Launchpad é horrível.

Todos 32 comentários

Com certeza, eu gostaria muito de ver isso. Mas pelo menos no momento não é realista que eu consiga manter o PPA e mantê-lo atualizado, então eu precisaria de alguma ajuda aqui. Se alguém puder configurar isso, seria incrível :)

É possível verificar se uma nova versão foi lançada? É uma boa ideia ver quando algo novo é lançado e eu acho que é possível executar algo como 'dpkg -i' para instalá-lo.

Sim, você pode navegar nesta página para ver os lançamentos mais recentes: Lançamentos . Há até um feed de átomo que você pode assistir!

E a próxima versão do Peek lhe dará um parâmetro de linha de comando "--version", para que você possa comparar facilmente sua versão local.

Eu poderia sugerir pular o estágio de PPA e ir direto para o empacotamento com o Snappy (com um DEB provavelmente desatualizado nos repositórios oficiais para quem quiser)? Eu acho que um dos pontos do Snappy é acabar com a necessidade de as pessoas terem que adicionar muitos PPAs para manter os pacotes atualizados mais do que os repositórios padrão. Tudo que você precisa fazer é fazer um Snap e, em seguida, enviá-lo para a loja oficial e voila, os usuários do Ubuntu (bem como os usuários Arch e Debian Unstable, e os usuários Fedora, Gentoo e OpenSUSE com o repositório Snappy habilitado) têm até date Peek. Não acho que seja muito difícil manter um Snap atualizado depois de feito.

Que tal um AppImage ?
Eu carreguei um experimental para
https://bintray.com/probono/AppImages/Peek/_latestVersion#files
Basta baixar o AppImage, torná-lo executável e executar. O GIF abaixo foi feito com ele :-)

Deve ser executado em distribuições de 2014 ou posteriores.
Algumas arestas esperadas, testes e polimento podem ser necessários.

makeexec

@phw deixe-me saber se você está interessado nisso. Se sim, posso estender seu .travis.yml modo que um AppImage novo e contínuo seja produzido em cada construção. (O AppImage acima foi feito a partir de debs usando essa receita , mas entendo que você está procurando por algo mais "ágil").

Bom trabalho

Tentei obter o Spotify Web Player para Linux (outro aplicativo FOSS) em um Snap, mas pode ser mais trabalhoso do que eu pensava para encaixar aplicativos ... ótimo AppImage é tão fácil

@ Ads20000 Verifique AppImageUpdate .

@probonopd Isso é bom, mas não parece muito automático (é descentralizado, afinal)? Eu gosto bastante do sistema Snappy, onde embora a loja padrão seja a do Ubuntu (o que o torna bastante centralizado), é possível configurar uma loja de aplicativos alternativa.

Ah, você é o criador / mantenedor do AppImageKit, não sabia! Bem, como eu disse, a atualização automática adequada eu acho que provavelmente é necessária se você quiser que este se torne o formato dominante. Também a capacidade de usar bibliotecas que já estão no sistema ou em outros AppImages (somente se forem da mesma versão) para reduzir o tamanho do arquivo? Se eles pudessem ser inteligentes e usar partes de bibliotecas em outras versões que são iguais, isso seria ainda mais legal.

Obrigado @probonopd por esse AppImage. A receita parece bastante simples e é fácil de executar. Infelizmente, aquele AppImage que você fez não funciona na minha instalação do Arch e, ao ser executado, falha com:

$ ./Peek-0.7.2.glibc2.14-x86_64.AppImage 
/tmp/.mount_GvkHNy/usr/bin/peek: symbol lookup error: /usr/lib/libpangoft2-1.0.so.0: undefined symbol: hb_buffer_set_cluster_level

Caso contrário, gosto da ideia, também de construí-lo automaticamente com travis. Seria possível oferecer também um de 32 bits (provavelmente requer que eu analise a compilação cruzada de 32 bits, algo que evitei até agora). Se você pudesse fornecer uma solicitação pull para isso, seria ótimo.

Meu principal problema com toda a embalagem é que eu não quero fazer isso sozinho e que devo fazer um mínimo de esforço ao ser lançado, já que, de qualquer forma, tenho dificuldade em encontrar tempo para desenvolvimento. Ter um PPA seria pelo menos algo que eu sei fazer, mas como eu não uso o Ubuntu, é difícil acompanhar todas as versões diferentes (eu sei, já que estou meio que mantendo o PPA para outro projeto e tem que procurar erros de compilação estranhos com freqüência quando novas versões do Ubuntu são disponibilizadas).

Imagens nítidas parecem interessantes, mas são para mim (apesar de todas as afirmações) muito específicas do Ubuntu. Por exemplo, não vejo nenhuma outra "app store", apesar da do Ubuntu. Se alguém quiser manter esse pacote, estou bem com isso, mas pelas razões acima, não serei eu.

Outra opção seria Flatpak, que pessoalmente acho mais interessante do que o Snappy, principalmente por causa de sua integração com o software Gnome.

Sim, eu concordo que @phw é provavelmente o maior problema do Snappy, apesar dos esforços do Ubuntu ainda, curiosamente, também Ubuntu-y.

Também acho que o propósito desses novos esforços era tentar torná-los sistemas de empacotamento universais fáceis o suficiente para que os próprios desenvolvedores pudessem empacotar e eliminar o intermediário, mas acho que se você realmente não tem tempo para empacotar, então isso pode ' t ser ajudado.

@phw não tem 100% de certeza, mas undefined symbol: hb_buffer_set_cluster_level parece um problema com seu sistema básico; consulte http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

Caso contrário, gosto da ideia, também de construí-lo automaticamente com travis.

Se você quiser seguir esse caminho, não precisa do pacote deb para produzir um AppImage. Exemplos:
https://github.com/search?q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22&type=Code&utf8=%E2%9C%93

Seria possível oferecer também um de 32 bits (provavelmente requer que eu analise a compilação cruzada de 32 bits, algo que evitei até agora). Se você pudesse fornecer uma solicitação pull para isso, seria ótimo.

Não investiguei muito esta área, mas é definitivamente factível; o projeto MuseScore fornece AppImages para x86_64, i686 e armhf (por exemplo, Raspberry Pi).

Meu principal problema com toda a embalagem é que eu não quero fazer isso sozinho e que deve fazer um mínimo de esforço ao liberar

AppImage é feito com este caso de uso em mente ... :)

Ter um PPA seria pelo menos algo que eu sei fazer

Em seguida, você pode usar algo como a receita que postei acima para converter debs no (de preferência confiável ou mais antigo) ppa para um AppImage na maior parte automaticamente.

Ter um PPA seria pelo menos algo que eu sei fazer

Em seguida, você pode usar algo como a receita que postei acima para converter debs no (de preferência confiável ou mais antigo) ppa para um AppImage na maior parte automaticamente.

Esse também é um plano possível para a construção de 32 bits. É provavelmente mais fácil configurar o PPA (obtendo compilações de 32 bits gratuitamente) do que adicionar a compilação cruzada à compilação CMake.

@phw não é 100% certo, mas símbolo indefinido: hb_buffer_set_cluster_level parece ser um problema com seu sistema básico; consulte http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

Prefiro suspeitar de algo errado com as bibliotecas nas quais isso foi criado, pois tenho versões muito recentes e geralmente não modificadas de todas as bibliotecas do meu sistema. Minha aposta é frequentemente em algum patch do Debian / Ubuntu acontecendo :)

Com base na sua receita, não está totalmente claro para mim como e de onde os binários Peek para o AppImage são obtidos. É algo especificado ao criar o AppImage final da receita?

Com base na sua receita, não está totalmente claro para mim como e de onde os binários Peek para o AppImage são obtidos. É algo especificado ao criar o AppImage final da receita?

O script que executa a receita está em https://github.com/probonopd/AppImages/blob/master/recipes/meta/Recipe

Que tal este repositório OBS Ubuntu ? Quem o mantém e é "oficial"? Entrei em contato com Andrew em webupd8.org para fornecer e manter um PPA para Peek. Se este OBS não for mais mantido, Andrew poderia ajudar.

Acho que é o mencionado pelo usuário em:
http://www.omgubuntu.co.uk/2016/08/peek-desktop-gif-screen-recorder-linux#comment -2894366969

Parece que ele não quer gerenciá-lo, mas eu poderia pedir a ele para me dar acesso ou pelo menos a configuração usada. OBS teria o benefício de poder ser construído também para outros sistemas. Por outro lado, achei OBS um pouco desagradável de usar da última vez que tentei.

Cabe a você decidir. Como eu disse, se você preferir um PPA, Andrew pode ajudar ;-)

@phw

Posso criar uma visão geral do meu próprio PPA. Mas para fazer isso corretamente, você precisa configurá-lo adequadamente na barra de lançamento para que não precise mantê-lo. Ele será compilado automaticamente quando detectar novas alterações.

1, Primeiro crie um novo projeto na barra de lançamento chamado "Peek" . Crie um PPA (denominado "peek-daily") no projeto.

  1. Em projeto-> código, selecione importar. Selecione o destino e a origem como git. Dê um nome à ramificação principal (por exemplo: tronco ). Obviamente, o dono deve ser você mesmo

  2. setup1

  3. Crie um novo repo "Peek-Packaging" no GitHub que deve conter apenas a pasta debian (você pode copiar do repo OBS)

  4. Importe o repo de embalagem da mesma maneira que o repo principal. Dê qualquer nome durante a importação como "debian-packaging"

  5. Vá para Projeto (ou seja, espreitar) -> código-> visualizar repositórios git. Clique em lp:~USERNAME/kee/+git/trunk . Em seguida, clique em create a packaging recipe .

  6. Dê um nome à receita. Selecione seu próprio PPA e verifique a série de distribuição. (picante, xenial ... etc)

  7. Agora o conteúdo da receita. Deve ser assim:

# git-build-recipe format 0.4 deb-version {debupstream}+{time}
lp:~USERNAME/keep/+git/trunk master
nest-part packaging lp:~USERNAME/keep/+git/debian-packaging debian debian master
  1. Salve-o e clique em "Solicitar construção". Ele começará a construir seu código! Para erros, verifique os logs de construção. Não se confunda com o nome "build-daily". Ele só é compilado quando detecta quaisquer alterações no repositório principal ou de empacotamento.

  2. FEITO!

Ele importará apenas o branch master. Você pode usar uma ramificação separada para lançamentos. Durante a criação da receita, você pode usar esse ramo específico em vez do tronco.

Ok, estamos chegando a algum lugar :) Finalmente comecei a fazer isso, agora há um PPA de compilação diária em:

https://code.launchpad.net/~peek-developers/+archive/ubuntu/daily

O código é construído usando esta receita: https://code.launchpad.net/~peek-developers/+recipe/peek-daily
As informações do pacote estão na verdade em um branch órfão no repositório principal Peek git, consulte https://github.com/phw/peek/tree/debian-packaging

Eu apreciaria se alguém pudesse ter um tear sobre isso e me dar algum feedback, já que faz muito tempo desde que brinquei com o pacote Debian e os PPAs do Launchpad, e a IU do Launchpad é horrível.

@phw de onde eu estou, isso é realmente direto e funciona bem. Obrigado.

$ sudo add-apt-repository ppa:peek-developers/daily
[sudo] password for anavarre: 
 Daily builds for the Peek animated GIF recorder
 More info: https://launchpad.net/~peek-developers/+archive/ubuntu/daily
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmp_lh3fua0/secring.gpg' created
gpg: keyring `/tmp/tmp_lh3fua0/pubring.gpg' created
gpg: requesting key 76BAFBC6 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmp_lh3fua0/trustdb.gpg: trustdb created
gpg: key 76BAFBC6: public key "Launchpad PPA for Peek Developers" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
$ sudo apt-get update
(snipped)
Fetched 2,348 kB in 2s (990 kB/s)
Reading package lists... Done
$ sudo apt-cache search ^peek
peek - create animated GIF screencasts
$ sudo apt-get install peek
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  peek
0 upgraded, 1 newly installed, 0 to remove and 7 not upgraded.
Need to get 63.5 kB of archives.
After this operation, 263 kB of additional disk space will be used.
Get:1 http://ppa.launchpad.net/peek-developers/daily/ubuntu xenial/main amd64 peek amd64 0.8.0-0~ppa201702141228~ubuntu16.04.1 [63.5 kB]
Fetched 63.5 kB in 0s (260 kB/s)
Selecting previously unselected package peek.
(Reading database ... 270537 files and directories currently installed.)
Preparing to unpack .../peek_0.8.0-0~ppa201702141228~ubuntu16.04.1_amd64.deb ...
Unpacking peek (0.8.0-0~ppa201702141228~ubuntu16.04.1) ...
Processing triggers for bamfdaemon (0.5.3~bzr0+16.04.20160824-0ubuntu1) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for gnome-menus (3.13.3-6ubuntu3.1) ...
Processing triggers for desktop-file-utils (0.22-1ubuntu5) ...
Processing triggers for mime-support (3.59ubuntu1) ...
Processing triggers for libglib2.0-0:i386 (2.48.2-0ubuntu1) ...
Processing triggers for libglib2.0-0:amd64 (2.48.2-0ubuntu1) ...
Processing triggers for hicolor-icon-theme (0.15-0ubuntu1) ...
Setting up peek (0.8.0-0~ppa201702141228~ubuntu16.04.1) ...

@phw Funcionando maravilhosamente bem. Obrigado.

@phw seria possível adicionar confiável e / ou preciso ao ppa?
Obrigado.

@probonopd Trusty está falhando devido à versão GTK, mas eu quero diminuir a versão necessária de qualquer maneira, consulte # 54.

Se isso corrigir a compilação também para o Precise, vou deixá-lo compilar lá. Do contrário, não vou me preocupar com o Precise, pois seu fim de vida é iminente.

Aceita

@probonopd Eu tentei fazer este trabalho para Trust, mas decidi que não haverá compilações para trusty, Peek está usando muitos recursos que não estão disponíveis no Gtk 3.10 e as versões glib e gio que o confiável fornece e exigiriam soluções alternativas ou desativado, e isso será demais para eu suportar.

@probonopd Existe alguma maneira de contornar isso com o AppImage ou o Peek está um pouco integrado demais com o resto do sistema para que isso seja possível (ou seja, se você empacotou seu próprio GTK no AppImage e / ou eu fiz no Snap, então pode funcionar?)

Edit: Sim, você disse que isso está funcionando em mais de 2014 distros?

@ Ads20000, que

@probonopd Não, eu quis dizer que o Peek poderia

@ Ads20000 Sim, desde que a versão mais recente do GTK (que 3.10) seja compilada em uma distribuição mais antiga.

Ok, isso parece funcionar agora. Eu atualizei o README.

Existem dois PPAs agora, um com compilações diárias e outro para versões estáveis:

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

Zorono picture Zorono  ·  3Comentários

phw picture phw  ·  6Comentários

fbruetting picture fbruetting  ·  6Comentários

msongz picture msongz  ·  7Comentários

CasperHK picture CasperHK  ·  5Comentários