Peek: Fügen Sie Peek zu einem PPA hinzu

Erstellt am 31. Aug. 2016  ·  32Kommentare  ·  Quelle: phw/peek

Dies würde es uns ermöglichen, Peek zu aktualisieren, ohne das Deb-Installationsprogramm bei jeder Version erneut herunterladen zu müssen.

help wanted packaging

Hilfreichster Kommentar

Ok, wir kommen irgendwohin :) Ich habe endlich angefangen, dies in Gang zu bringen, es gibt jetzt eine tägliche Build-PPA unter:

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

Der Code wird nach diesem Rezept erstellt: https://code.launchpad.net/~peek-developers/+recipe/peek-daily
Die Verpackungsinformationen befinden sich tatsächlich in einer verwaisten Filiale im Haupt-Repository von Peek Git, siehe https://github.com/phw/peek/tree/debian-packaging

Ich würde mich freuen, wenn jemand einen Webstuhl dazu haben und mir Feedback geben könnte, da ich schon sehr lange nicht mehr mit Debian-Verpackungen und Launchpad-PPAs herumgespielt habe und die Launchpad-Benutzeroberfläche schrecklich ist.

Alle 32 Kommentare

Auf jeden Fall würde ich das sehr gerne sehen. Aber zumindest im Moment ist es unrealistisch, dass ich das PPA beibehalten und auf dem neuesten Stand halten kann, daher würde ich hier Hilfe benötigen. Wenn jemand dies einrichten kann, wäre es fantastisch :)

Kann überprüft werden, ob eine neue Version veröffentlicht wurde? Es ist eine gute Idee zu sehen, wann etwas Neues veröffentlicht wird, und ich denke, es ist möglich, etwas wie 'dpkg -i' auszuführen, um es zu installieren.

Ja, Sie können diese Seite durchsuchen, um die neuesten Versionen anzuzeigen : Versionen. Es gibt sogar einen Atom-Feed, den Sie sehen können!

In der nächsten Version von Peek erhalten Sie einen Befehlszeilenparameter "--version", mit dem Sie Ihre lokale Version problemlos vergleichen können.

Könnte ich vorschlagen, die PPA-Phase zu überspringen und direkt mit Snappy zu verpacken (mit einer wahrscheinlich veralteten DEB in den offiziellen Repositories für diejenigen, die dies wünschen)? Ich denke, einer der Punkte von Snappy ist es, die Notwendigkeit zu beenden, dass Benutzer viele PPAs hinzufügen müssen, um Pakete aktueller zu halten als die Standard-Repositorys. Alles, was Sie tun müssen, ist, einen Snap zu erstellen und ihn dann in den offiziellen Store hochzuladen. Voila, Ubuntu-Benutzer (sowie Arch- und Debian Unstable-Benutzer sowie Fedora-, Gentoo- und OpenSUSE-Benutzer mit aktiviertem Snappy-Repository) haben bis zu Datum Peek. Ich denke nicht, dass es zu schwierig ist, einen Snap auf dem neuesten Stand zu halten, sobald er erstellt wurde.

Wie wäre es mit einem AppImage ?
Ich habe einen experimentellen hochgeladen
https://bintray.com/probono/AppImages/Peek/_latestVersion#files
Laden Sie einfach das AppImage herunter, machen Sie es ausführbar und führen Sie es aus. Das GIF unten wurde damit gemacht :-)

Sollte auf 2014ish oder späteren Distributionen laufen.
Einige raue Kanten werden erwartet, möglicherweise sind Tests und Polierungen erforderlich.

makeexec

@phw lass es mich wissen, wenn du daran interessiert bist. Wenn ja, kann ich Ihr vorhandenes .travis.yml sodass bei jedem Build ein neues, kontinuierliches AppImage erstellt wird. (Das obige AppImage wurde nach diesem Rezept aus Debs erstellt, aber ich verstehe, dass Sie nach etwas "Agilerem" suchen.)

Großartige Arbeit @probonopd (Ich bin hier kein Mitwirkender, aber gut gemacht, um es zu erledigen)! Je mehr Paketformate desto besser (solange sie relativ wartungsarm sind und Formate wie Snappy und AppImage, glaube ich, normalerweise nach Abschluss der ersten Implementierung), ist Snappy meiner Meinung nach besser, da sie automatisch aktualisiert werden .

Ich habe versucht, Spotify Web Player für Linux (eine andere FOSS-Anwendung) in einem Snap zu bündeln, aber es könnte mehr Arbeit sein, als ich dachte, um Anwendungen zu fangen ... großartiges AppImage ist so einfach

@ Ads20000 Überprüfen Sie AppImageUpdate .

@probonopd Das ist gut, aber das sieht nicht sehr automatisch aus (es ist schließlich dezentral)? Ich mag das Snappy-System sehr, bei dem der Standard-Store zwar der Ubuntu-Store ist (wodurch er ziemlich zentralisiert ist), es aber möglich ist, einen alternativen App-Store einzurichten.

Oh, Sie sind der Schöpfer / Betreuer von AppImageKit, haben es nicht bemerkt! Wie ich bereits sagte, ist eine ordnungsgemäße automatische Aktualisierung wahrscheinlich erforderlich, wenn Sie möchten, dass dies das dominierende Format wird. Auch die Möglichkeit, Bibliotheken zu verwenden, die sich bereits auf dem System oder in anderen AppImages befinden (nur wenn sie dieselbe Version haben), um die Dateigröße zu verringern? Wenn sie intelligent sein und Teile von Bibliotheken in anderen Versionen verwenden könnten, die gleich sind, wäre das noch cooler.

Danke @probonopd für das AppImage. Das Rezept sieht einfach aus und ist einfach auszuführen. Leider läuft das von Ihnen erstellte AppImage nicht auf meiner Arch-Installation und schlägt bei der Ausführung fehl mit:

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

Ansonsten gefällt mir die Idee, es auch automatisch mit Travis zu bauen. Wäre es möglich, auch eine 32-Bit-Version anzubieten (wahrscheinlich muss ich mich mit der 32-Bit-Cross-Kompilierung befassen, was ich bisher vermieden habe). Wenn Sie eine Pull-Anfrage dafür stellen könnten, wäre es großartig.

Mein Hauptproblem bei allen Verpackungen ist, dass ich es nicht selbst machen möchte und dass es beim Release einen minimalen Aufwand bedeuten sollte, da ich sowieso Probleme habe, die Zeit für die Entwicklung zu finden. Eine PPA zu haben wäre zumindest etwas gewesen, von dem ich weiß, wie man es macht, aber da ich Ubuntu selbst nicht benutze, ist es schwierig, mit allen verschiedenen Versionen Schritt zu halten (ich weiß, da ich die PPA für ein anderes Projekt pflege und müssen häufig auf seltsame Build-Fehler achten, wenn neue Ubuntu-Versionen verfügbar werden).

Bissige Bilder klingen interessant, sind aber für mich (trotz aller Behauptungen) sehr Ubuntu-spezifisch. ZB sehe ich trotz Ubuntu keinen anderen "App Store". Wenn jemand ein solches Paket pflegen möchte, bin ich damit einverstanden, aber aus den oben genannten Gründen bin ich es nicht.

Eine weitere Option wäre Flatpak, das ich persönlich interessanter finde als Snappy, nicht zuletzt wegen seiner Integration in Gnome Software.

Ja, ich stimme zu, @phw , das ist wahrscheinlich

Ich denke auch, dass der Zweck dieser neuen Bemühungen darin bestand, sie so einfach zu machen, dass die Entwickler selbst den Mittelsmann verpacken und ausschneiden konnten, aber ich denke, wenn Sie nicht wirklich die Zeit zum Verpacken haben, kann das. ' t geholfen werden.

@phw nicht 100% sicher, aber undefined symbol: hb_buffer_set_cluster_level scheint ein Problem mit Ihrem Basissystem zu sein; Siehe http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

Ansonsten gefällt mir die Idee, es auch automatisch mit Travis zu bauen.

Wenn Sie diesen Weg gehen möchten, benötigen Sie keine Deb-Verpackung, um ein AppImage zu erstellen. Beispiele:
https://github.com/search?q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22&type=Code&utf8=%E2%9C%93

Wäre es möglich, auch eine 32-Bit-Version anzubieten (wahrscheinlich muss ich mich mit der 32-Bit-Cross-Kompilierung befassen, was ich bisher vermieden habe). Wenn Sie eine Pull-Anfrage dafür stellen könnten, wäre es großartig.

Ich habe dieses Gebiet nicht viel untersucht, aber es ist definitiv machbar. Das MuseScore-Projekt bietet AppImages für x86_64, i686 und armhf (z. B. Raspberry Pi).

Mein Hauptproblem bei allen Verpackungen ist, dass ich es nicht selbst machen möchte und dass es beim Freigeben einen minimalen Aufwand bedeuten sollte

AppImage wurde unter Berücksichtigung dieses Anwendungsfalls erstellt ... :)

Ein PPA zu haben, wäre zumindest etwas gewesen, von dem ich weiß, wie man es macht

Dann können Sie so etwas wie das Rezept, das ich oben gepostet habe, verwenden, um Debs im (idealerweise vertrauenswürdigen oder älteren) ppa meist automatisch in ein AppImage umzuwandeln.

Ein PPA zu haben, wäre zumindest etwas gewesen, von dem ich weiß, wie man es macht

Dann können Sie so etwas wie das Rezept, das ich oben gepostet habe, verwenden, um Debs im (idealerweise vertrauenswürdigen oder älteren) ppa meist automatisch in ein AppImage umzuwandeln.

Dies ist auch ein möglicher Plan für den 32-Bit-Build. Es ist wahrscheinlich einfacher, die PPA einzurichten (32-Bit-Builds kostenlos zu erhalten), als die Cross-Kompilierung zum CMake-Build hinzuzufügen.

@phw nicht 100% sicher, aber undefiniertes Symbol: hb_buffer_set_cluster_level scheint ein Problem mit Ihrem Basissystem zu sein; Siehe http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

Ich vermute eher, dass etwas mit den Bibliotheken, gegen die dies erstellt wurde, nicht stimmt, da ich sehr aktuelle und normalerweise unveränderte Versionen aller Bibliotheken auf meinem System habe. Ich wette oft, dass Debian / Ubuntu-Patches stattfinden :)

Aus Ihrem Rezept ist mir nicht ganz klar, wie und woher die Peek-Binärdateien für das AppImage stammen. Ist dies beim Erstellen des endgültigen AppImage aus dem Rezept angegeben?

Aus Ihrem Rezept ist mir nicht ganz klar, wie und woher die Peek-Binärdateien für das AppImage stammen. Ist dies beim Erstellen des endgültigen AppImage aus dem Rezept angegeben?

Das Skript, mit dem das Rezept ausgeführt wird, befindet sich unter https://github.com/probonopd/AppImages/blob/master/recipes/meta/Recipe

Was ist mit diesem OBS Ubuntu-Repository ? Wer unterhält es und ist es "offiziell"? Ich habe Andrew von webupd8.org kontaktiert, um eine PPA für Peek bereitzustellen und zu pflegen. Wenn diese OBS nicht mehr gepflegt wird, könnte Andrew helfen.

Ich denke, das ist der vom Benutzer erwähnte unter:
http://www.omgubuntu.co.uk/2016/08/peek-desktop-gif-screen-recorder-linux#comment -2894366969

Sieht nicht so aus, als würde er es verwalten wollen, aber ich könnte ihn bitten, mir Zugriff zu gewähren oder zumindest die verwendete Konfiguration. OBS hätte den Vorteil, dass es auch für andere Systeme gebaut werden könnte. Andererseits fand ich es etwas unangenehm, OBS beim letzten Versuch zu verwenden.

Es liegt an Ihnen zu entscheiden. Wie gesagt, wenn Sie eine PPA bevorzugen, kann Andrew helfen ;-)

@phw

Ich kann einen Blick in meine eigene PPA werfen. Aber um es richtig zu machen, müssen Sie es richtig auf dem Launchpad einrichten, damit Sie es nicht warten müssen. Es wird automatisch kompiliert, wenn neue Änderungen erkannt werden.

1, erstelle zuerst ein neues Projekt auf dem Launchpad mit dem Namen "Peek" . Erstellen Sie unter dem Projekt eine PPA (mit dem Namen "Peek-Daily").

  1. Wählen Sie unter Projekt-> Code Import. Wählen Sie Ziel und Quelle als Git. Geben Sie dem Hauptzweig einen Namen (zum Beispiel: Stamm ). Offensichtlich sollte der Besitzer Sie selbst sein

  2. setup1

  3. Erstellen Sie ein neues Repo "Peek-Packaging" bei GitHub, das nur den Debian- Ordner enthalten darf (Sie können es aus dem OBS-Repo kopieren).

  4. Importieren Sie das Verpackungs-Repo auf die gleiche Weise wie das Haupt-Repo. Geben Sie während des Imports einen beliebigen Namen wie "Debian-Verpackung" an

  5. Gehen Sie zu Projekt (dh Peek) -> Code-> Git-Repositorys anzeigen. Klicken Sie auf lp:~USERNAME/kee/+git/trunk . Klicken Sie dann auf create a packaging recipe .

  6. Geben Sie einen Rezeptnamen an. Wählen Sie Ihre eigene PPA aus und überprüfen Sie die Verteilungsreihen. (pikant, xenial ... etc)

  7. Nun der Rezeptinhalt. Es sollte so aussehen:

# 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. Speichern Sie es und klicken Sie auf "Build anfordern". Es wird beginnen, Ihren Code zu erstellen! Überprüfen Sie die Build-Protokolle auf Fehler. Verwechseln Sie sich nicht mit dem Namen "build-daily". Es wird nur erstellt, wenn Änderungen im Haupt- oder Verpackungs-Repo festgestellt werden.

  2. ERLEDIGT!

Es wird nur der Hauptzweig importiert. Sie können einen separaten Zweig für Releases verwenden. Während der Rezepterstellung können Sie diesen bestimmten Zweig anstelle von Trunk verwenden.

Ok, wir kommen irgendwohin :) Ich habe endlich angefangen, dies in Gang zu bringen, es gibt jetzt eine tägliche Build-PPA unter:

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

Der Code wird nach diesem Rezept erstellt: https://code.launchpad.net/~peek-developers/+recipe/peek-daily
Die Verpackungsinformationen befinden sich tatsächlich in einer verwaisten Filiale im Haupt-Repository von Peek Git, siehe https://github.com/phw/peek/tree/debian-packaging

Ich würde mich freuen, wenn jemand einen Webstuhl dazu haben und mir Feedback geben könnte, da ich schon sehr lange nicht mehr mit Debian-Verpackungen und Launchpad-PPAs herumgespielt habe und die Launchpad-Benutzeroberfläche schrecklich ist.

@phw von wo ich sitze das ist wirklich einfach und funktioniert gut. Dankeschön.

$ 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 Wunderbar gut

@phw wäre es möglich, dem ppa vertrauenswürdig und / oder präzise hinzuzufügen?
Vielen Dank.

@probonopd Trusty fehl , aber ich möchte die erforderliche Version trotzdem senken, siehe # 54.

Wenn das den Build auch für Precise behebt, lasse ich ihn auch dort bauen. Ansonsten werde ich mich nicht um Precise kümmern, da das Ende des Lebens unmittelbar bevorsteht.

Zustimmen

@probonopd Ich habe versucht, diese Arbeit für Trust zu bekommen, aber ich habe entschieden, dass es keine Builds für Trusty geben wird. Peek verwendet zu viele Funktionen, die in Gtk 3.10 nicht verfügbar sind, und die vertrauenswürdigen Versionen glib und gio bieten Workarounds oder das Abrufen deaktiviert, und das wird zu viel für mich zu unterstützen.

@probonopd Gibt es eine Möglichkeit, dies mit AppImage zu umgehen, oder ist Peek etwas zu stark in den Rest des Systems integriert, als dass dies möglich wäre (dh wenn Sie Ihre eigene GTK in AppImage gebündelt haben und / oder ich dies in Snap getan habe) es könnte klappen?)

Edit: Ja, du hast gesagt, dass du das für 2014+ Distributionen hast?

@ Ads20000 , der das AppImage zusammenstellt, kann entscheiden, was gebündelt und was von den Zielsystemen verwendet werden soll. Das Peek-Projekt könnte beschließen, Gtk 3.10 und die von Peek benötigten Glib- und Gio-Versionen als private Kopien in AppImage zu bündeln. Trotzdem sollten Gtk 3.10, glib und gio auf den ältesten Systemen kompiliert werden, auf denen sie noch kompiliert werden können, um nicht die neuesten Versionen von glibc usw. zu zeichnen. Das Ergebnis wäre ein größeres AppImage, das auch bei älteren Distributionen funktioniert.

@probonopd Nein, ich meinte, könnte Peek eine neuere Version von GTK (als 3.10) in AppImage bündeln, damit es auf älteren Distributionen funktioniert?

@ Ads20000 Ja, solange die neuere Version von GTK (als 3.10) auf einer älteren Distribution kompiliert wird.

Ok, das scheint jetzt zu funktionieren. Ich habe die README aktualisiert.

Derzeit gibt es zwei PPAs, einen mit täglichen Builds und einen für stabile Releases:

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Art-2 picture Art-2  ·  6Kommentare

ArsenArsen picture ArsenArsen  ·  3Kommentare

CasperHK picture CasperHK  ·  5Kommentare

msongz picture msongz  ·  7Kommentare

grimmer-std picture grimmer-std  ·  6Kommentare