Peek: Ajouter Peek à un PPA

Absolument, j'aimerais beaucoup voir cela. Mais au moins pour le moment, il n'est pas réaliste que je puisse maintenir le PPA et le tenir à jour, donc j'aurais besoin d'aide ici. Si quelqu'un peut configurer cela, ce serait génial :)

Est-il possible de vérifier si une nouvelle version est sortie? C'est une bonne idée de voir quand quelque chose de nouveau est publié et je pense qu'il est possible d'exécuter quelque chose comme «dpkg -i» pour l'installer.

Oui, vous pouvez parcourir cette page pour voir les dernières versions: Versions . Il y a même un flux atomique que vous pouvez regarder!

Et la prochaine version de Peek vous donnera un paramètre de ligne de commande "--version", afin que vous puissiez facilement comparer votre version locale.

Puis-je suggérer de sauter l'étape PPA et de passer directement à l'empaquetage avec Snappy (avec un DEB probablement obsolète dans les référentiels officiels pour ceux qui le souhaitent)? Je pense que l'un des points de Snappy est de mettre fin à la nécessité pour les gens d'avoir à ajouter beaucoup de PPA pour maintenir les packages à jour plus que les référentiels par défaut. Tout ce que vous avez à faire est de créer un Snap, puis de le télécharger sur la boutique officielle et le tour est joué, les utilisateurs d'Ubuntu (ainsi que les utilisateurs Arch et Debian Unstable, et les utilisateurs de Fedora, Gentoo et OpenSUSE avec le référentiel Snappy activé) ont jusqu'à- date Peek. Je ne pense pas qu'il soit trop difficile de garder un Snap à jour une fois qu'il a été créé.

Et une
J'ai téléchargé une version expérimentale sur
https://bintray.com/probono/AppImages/Peek/_latestVersion#files
Téléchargez simplement AppImage, rendez-le exécutable et exécutez. Le GIF ci-dessous a été fait avec :-)

Doit fonctionner sur des distributions de 2014 ou ultérieures.
Quelques bords rugueux attendus, des tests et un polissage peuvent être nécessaires.

@phw faites-moi savoir si cela vous intéresse. Si oui, je peux étendre votre .travis.yml existant afin qu'une nouvelle AppImage continue soit produite sur chaque build. (L'AppImage ci-dessus a été faite à partir de debs en utilisant cette recette , mais je comprends que vous cherchez quelque chose de plus "agile").

Excellent travail @probonopd (je ne suis pas un contributeur ici mais bravo pour l'avoir fait)! Plus il y a de formats de paquet, mieux c'est (tant qu'ils nécessitent peu de maintenance et que des formats tels que Snappy et AppImage, je pense, le sont généralement une fois que vous avez terminé l'implémentation initiale), je pense que Snappy est meilleur car ils se mettent à jour automatiquement .

J'ai jeté un coup d'œil à essayer d'obtenir Spotify Web Player pour Linux (une autre application FOSS) regroupée dans un Snap, mais cela pourrait être plus de travail que je ne le pensais de prendre des applications ... super AppImage est si facile

@ Ads20000 Vérifiez AppImageUpdate .

@probonopd C'est bien mais ça n'a pas l'air très automatique (c'est décentralisé, après tout)? J'aime assez le système Snappy où, bien que le magasin par défaut soit celui d'Ubuntu (ce qui le rend assez centralisé), il est possible de créer un magasin d'applications alternatif.

Oh, vous êtes le créateur / mainteneur d'AppImageKit, vous ne vous en êtes pas rendu compte! Eh bien, comme je l'ai dit, une mise à jour correctement automatique, je pense, est probablement nécessaire si vous voulez que ce format devienne le format dominant. Également la possibilité d'utiliser des bibliothèques déjà présentes sur le système ou dans d'autres AppImages (uniquement si elles sont de la même version) pour réduire la taille du fichier? S'ils pouvaient être intelligents et utiliser des parties de bibliothèques dans d'autres versions qui sont identiques, ce serait encore plus cool.

Merci @probonopd pour cette AppImage. La recette semble assez simple et facile à exécuter. Malheureusement, AppImage que vous avez créée ne fonctionne pas sur mon installation Arch et échoue lors de son exécution avec:

$ ./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

Sinon j'aime l'idée, aussi de le construire automatiquement avec travis. Serait-il possible d'en proposer également un 32 bits (cela me demande probablement de me pencher sur la compilation croisée 32 bits, ce que j'ai évité jusqu'à présent). Si vous pouviez fournir une pull request pour cela, ce serait génial.

Mon principal problème avec tous les emballages est que je ne veux pas le faire moi-même et qu'il devrait faire un minimum d'efforts lors de la sortie, car j'ai de toute façon des problèmes à trouver le temps pour le développement. Avoir un PPA aurait au moins été quelque chose que je sais faire, mais comme je n'utilise pas Ubuntu moi-même, il est difficile de suivre toutes les versions différentes (je sais, car je maintiens en quelque sorte le PPA pour un autre projet et doivent examiner fréquemment des erreurs de construction étranges lorsque de nouvelles versions d'Ubuntu deviennent disponibles).

Les images Snappy semblent intéressantes, mais elles sont pour moi (malgré toutes les affirmations) très spécifiques à Ubuntu. Par exemple, je ne vois aucun autre "app store" malgré celui d'Ubuntu. Si quelqu'un veut maintenir un tel paquet, je suis d'accord, mais pour les raisons ci-dessus, ce ne sera pas moi.

Une autre option serait Flatpak, que je trouve personnellement plus intéressante que Snappy, notamment en raison de son intégration dans Gnome Software.

Oui, je suis d'accord @phw, c'est probablement le plus gros problème de Snappy, malgré les efforts d'Ubuntu, c'est toujours, assez drôle, trop Ubuntu-y.

Je pense également que le but de ces nouveaux efforts était d'essayer de rendre les systèmes d'emballage universels suffisamment simples pour que les développeurs eux-mêmes puissent empaqueter et éliminer les intermédiaires, mais je suppose que si vous n'avez pas vraiment le temps de créer des packages, cela peut ' t être aidé.

@phw n'est pas sûr à 100% mais undefined symbol: hb_buffer_set_cluster_level semble être un problème avec votre système de base; voir http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

Sinon j'aime l'idée, aussi de le construire automatiquement avec travis.

Si vous souhaitez suivre cette voie, vous n'avez pas besoin de l'empaquetage deb pour produire une AppImage. Exemples:
https://github.com/search?q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22&type=Code&utf8=%E2%9C%93

Serait-il possible d'en proposer également un 32 bits (cela me demande probablement de me pencher sur la compilation croisée 32 bits, ce que j'ai évité jusqu'à présent). Si vous pouviez fournir une pull request pour cela, ce serait génial.

Je n'ai pas beaucoup étudié ce domaine, mais c'est définitivement faisable; le projet MuseScore fournit des AppImages pour x86_64, i686 et armhf (par exemple, Raspberry Pi).

Mon principal problème avec tous les emballages est que je ne veux pas le faire moi-même et qu'il devrait faire un minimum d'efforts lors de la sortie

AppImage est conçu avec ce cas d'utilisation à l'esprit ... :)

Avoir un PPA aurait au moins été quelque chose que je sais faire

Ensuite, vous pouvez utiliser quelque chose comme la recette que j'ai publiée ci-dessus pour convertir les debs dans le ppa (idéalement fiable ou plus ancien) en AppImage le plus souvent automatiquement.

Avoir un PPA aurait au moins été quelque chose que je sais faire

Ensuite, vous pouvez utiliser quelque chose comme la recette que j'ai publiée ci-dessus pour convertir les debs dans le ppa (idéalement fiable ou plus ancien) en AppImage le plus souvent automatiquement.

C'est aussi un plan possible pour la construction 32 bits. Il est probablement plus facile de configurer le PPA (obtenir gratuitement des versions 32 bits) puis d'ajouter la compilation croisée à la version CMake.

@phw n'est pas sûr à 100% mais symbole non défini: hb_buffer_set_cluster_level semble être un problème avec votre système de base; voir http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

Je soupçonne plutôt que quelque chose ne va pas avec les bibliothèques sur lesquelles cela a été construit, car j'ai des versions très récentes et généralement non modifiées de toutes les bibliothèques de mon système. Je parie souvent que des correctifs Debian / Ubuntu sont en cours :)

D'après votre recette, il ne m'est pas tout à fait clair comment et d'où les binaires Peek pour AppImage sont obtenus. Est-ce quelque chose de spécifié lors de la création de l'AppImage finale à partir de la recette?

D'après votre recette, il ne m'est pas tout à fait clair comment et d'où les binaires Peek pour AppImage sont obtenus. Est-ce quelque chose de spécifié lors de la création de l'AppImage finale à partir de la recette?

Le script qui exécute la recette est sur https://github.com/probonopd/AppImages/blob/master/recipes/meta/Recipe

Qu'en est-il de ce référentiel OBS Ubuntu ? Qui le maintient et est-ce «officiel»? J'ai contacté Andrew de webupd8.org pour fournir et maintenir un PPA pour Peek. Si cet OBS n'est plus maintenu, Andrew pourrait vous aider.

Je pense que c'est celui mentionné par l'utilisateur à:
http://www.omgubuntu.co.uk/2016/08/peek-desktop-gif-screen-recorder-linux#comment -2894366969

Il n'a pas l'air de vouloir le gérer, mais je pourrais lui demander de me donner l'accès ou du moins la configuration utilisée. OBS aurait l'avantage qu'il pourrait également construire pour d'autres systèmes. D'un autre côté, j'ai trouvé OBS un peu désagréable à utiliser la dernière fois que j'ai essayé.

C'est à vous de décider. Comme je l'ai dit, si vous préférez un PPA, Andrew peut vous aider ;-)

@phw

Je peux créer un aperçu de mon propre PPA. Mais pour le faire correctement, vous devez le configurer correctement sur le tableau de bord afin de ne pas avoir à le maintenir. Il se compilera automatiquement lorsqu'il détectera de nouveaux changements.

1, créez d'abord un nouveau projet sur le tableau de bord nommé «Peek» . Créez un PPA (nommé «peek-daily») sous le projet.

1. Sous projet-> code, sélectionnez importer. Sélectionnez la cible et la source en tant que git. Donnez un nom à la branche principale (par exemple: trunk ). De toute évidence, le propriétaire devrait être vous-même

2. 

3. Créez un nouveau dépôt "Peek-Packaging" sur GitHub qui ne doit contenir que le dossier debian (vous pouvez copier depuis le dépôt OBS)

4. Importez le référentiel de packaging de la même manière que le référentiel principal. Donnez n'importe quel nom lors de l'importation comme "debian-packaging"

5. Allez dans Project (ie peek) -> code-> view git repositories. Cliquez sur lp:~USERNAME/kee/+git/trunk . Cliquez ensuite sur create a packaging recipe .

6. Donnez un nom à la recette. Sélectionnez votre propre série de distribution PPA et chèque. (zesté, xenial ... etc)

7. Maintenant, le contenu de la recette. Ça devrait ressembler à ça:

# 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. Enregistrez-le et cliquez sur "Request Build". Il commencera à construire votre code! Pour les erreurs, vérifiez les journaux de construction. Ne vous méprenez pas avec le nom "build-daily". Il ne se construit que lorsqu'il détecte des modifications dans le référentiel principal ou dans le dépôt d'empaquetage.

2. TERMINÉ!

Il importera uniquement la branche principale. Vous pouvez utiliser une branche distincte pour les versions. Lors de la création de la recette, vous pouvez utiliser cette branche particulière au lieu du tronc.

Ok, nous allons quelque part :) J'ai enfin commencé à faire avancer les choses, il y a maintenant un PPA de construction quotidienne à:

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

Le code est construit en utilisant cette recette: https://code.launchpad.net/~peek-developers/+recipe/peek-daily
Les informations d'empaquetage se trouvent en fait dans une branche orpheline du référentiel principal Peek git, voir https://github.com/phw/peek/tree/debian-packaging

J'apprécierais que quelqu'un puisse avoir un métier à ce sujet et me faire part de ses commentaires, car cela fait très longtemps que je n'ai pas manipulé l'empaquetage Debian et les PPA Launchpad, et l'interface utilisateur du Launchpad est horrible.

@phw d'où je suis assis, c'est vraiment simple et fonctionne bien. Merci.

$ 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 Fonctionne merveilleusement bien. Merci.

@phw serait-il possible d'ajouter fidèle et / ou précis au ppa?
Merci.

@probonopd Trusty échoue actuellement en raison de la version GTK, mais je souhaite quand même baisser la version requise, voir # 54.

Si cela corrige également la construction pour Precise, je la laisserai également construire là-bas. Sinon, je ne vais pas m'embêter avec Precise car sa fin de vie est imminente.

Se mettre d'accord

@probonopd J'ai essayé d'obtenir ce travail pour Trust, mais j'ai décidé qu'il n'y aurait pas de builds pour Trusty, Peek utilise trop de fonctionnalités qui ne sont pas disponibles dans Gtk 3.10 et les versions glib et gio que Trusty fournit et nécessiteraient des solutions de contournement ou obtenir handicapés, et ce sera trop pour moi de soutenir.

@probonopd Existe-t-il un moyen de contourner ce problème avec AppImage ou Peek est-il un peu trop intégré au reste du système pour que cela soit possible (c'est-à-dire si vous avez regroupé votre propre GTK dans AppImage et / ou je l'ai fait dans le Snap, alors ça pourrait marcher?)

Edit: Oui, vous avez dit que cela fonctionnait sur les distributions 2014+?

@ Ads20000 qui assemble l'AppImage peut décider de ce qu'il faut regrouper et de ce qu'il faut utiliser à partir du ou des systèmes cibles. Le projet peek pourrait décider de regrouper Gtk 3.10 et les versions glib et gio requises par peek en tant que copies privées dans AppImage. Toujours Gtk 3.10, glib et gio doivent être compilés sur les systèmes les plus anciens sur lesquels ils peuvent encore être compilés, afin de ne pas utiliser les dernières versions de glibc, etc. Le résultat serait une AppImage plus grande qui fonctionnerait toujours sur les anciennes distributions.

@probonopd Non, je voulais dire que Peek pourrait regrouper une version plus récente de GTK (que 3.10) dans AppImage pour qu'elle fonctionne sur les anciennes distributions ??

@ Ads20000 Oui, tant que la version la plus récente de GTK (que 3.10) serait compilée sur une distribution plus ancienne.

Ok, cela semble fonctionner maintenant. J'ai mis à jour le README.

Il existe maintenant deux PPA, un avec des versions quotidiennes et un pour les versions stables:

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