Peek: Добавить Peek в PPA

Безусловно, я бы очень хотел это увидеть. Но, по крайней мере, на данный момент нереально, что я смогу поддерживать PPA и поддерживать его в актуальном состоянии, поэтому мне понадобится помощь. Если бы кто-нибудь мог это настроить, было бы здорово :)

Можно ли проверить, вышла ли новая версия? Хорошая идея - увидеть, когда будет выпущено что-то новое, и я думаю, что можно запустить что-то вроде «dpkg -i», чтобы установить это.

Да, действительно, вы можете просмотреть эту страницу, чтобы увидеть последние выпуски: Релизы . Есть даже атомный канал, который вы можете посмотреть!

А следующая версия Peek предоставит вам параметр командной строки «--version», чтобы вы могли легко сравнить свою локальную версию.

Могу ли я предложить пропустить этап PPA и сразу перейти к упаковке с помощью Snappy (с возможно устаревшим DEB в официальных репозиториях для тех, кто этого хочет)? Я думаю, что одна из задач Snappy - избавить людей от необходимости добавлять множество PPA, чтобы поддерживать пакеты в актуальном состоянии в большей степени, чем это делают репозитории по умолчанию. Все, что вам нужно сделать, это создать Snap, а затем загрузить его в официальный магазин и вуаля, пользователи Ubuntu (а также пользователи Arch и Debian Unstable, а также пользователи Fedora, Gentoo и OpenSUSE с включенным репозиторием Snappy) имеют до- свидание Peek. Я не думаю, что постоянно обновлять Snap после того, как он был сделан.

Как насчет AppImage ?
Я загрузил экспериментальную версию на
https://bintray.com/probono/AppImages/Peek/_latestVersion#files
Просто скачайте AppImage, сделайте его исполняемым и запустите. GIF ниже был сделан с его помощью :-)

Должен работать в дистрибутивах 2014 года или более поздних версий.
Ожидаются шероховатости, может потребоваться проверка и полировка.

@phw дайте мне знать, если вам это интересно. Если да, я могу расширить существующий .travis.yml чтобы при каждой сборке создавался новый непрерывный образ AppImage. (AppImage, приведенный выше, был создан из debs с использованием этого рецепта , но я понимаю, что вы ищете что-то более «гибкое»).

Отличная работа @probonopd (я не участвую в этом, но молодец, что сделал это)! Чем больше форматов пакетов, тем лучше (пока они довольно просты в обслуживании, а такие форматы, как Snappy и AppImage, я думаю, _ обычно_ появляются после того, как вы закончили начальную реализацию), я действительно думаю, что Snappy лучше, потому что они автоматически обновляются .

Я пытался связать Spotify Web Player для Linux (еще одно приложение FOSS) в Snap, но, возможно, для привязки приложений потребуется больше работы, чем я думал ... отличный AppImage - это так просто

@ Ads20000 Проверьте AppImageUpdate .

@probonopd Это хорошо, но это не выглядит автоматическим (в конце концов, это децентрализовано)? Мне очень нравится система Snappy, где, хотя магазином по умолчанию является Ubuntu (что делает его довольно централизованным), можно создать альтернативный магазин приложений.

О, вы создатель / сопровождающий AppImageKit, не понимали! Как я уже сказал, правильное автоматическое обновление, я думаю, вероятно, необходимо, если вы хотите, чтобы этот формат стал доминирующим. Также возможность использовать библиотеки, которые уже есть в системе или в других AppImages (только если они той же версии), чтобы уменьшить размер файла? Если бы они могли быть умными и использовать те же части библиотек в других версиях, это было бы еще круче.

Спасибо @probonopd за этот AppImage. Рецепт выглядит достаточно просто, и его легко запустить. К сожалению, созданный вами AppImage не запускается в моей установке Arch, и после его выполнения происходит сбой:

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

В остальном мне нравится идея, а также автоматическое построение с помощью Трэвиса. Можно ли было бы также предложить 32-битную (возможно, мне потребуется изучить 32-битную кросс-компиляцию, чего я до сих пор избегал). Если бы вы могли предоставить для этого пул-реквест, было бы здорово.

Моя основная проблема со всей упаковкой заключается в том, что я не хочу делать это сам и что при выпуске нужно приложить минимум усилий, поскольку у меня все равно есть проблемы с поиском времени для разработки. По крайней мере, иметь PPA было бы чем-то, что я знаю, но поскольку я сам не использую Ubuntu, мне трудно идти в ногу со всеми различными версиями (я знаю, поскольку я как бы поддерживаю PPA для другого проекта и При появлении новых версий Ubuntu приходится часто обнаруживать странные ошибки сборки).

Мгновенные изображения звучат интересно, но для меня (несмотря на все заявления) они очень специфичны для Ubuntu. Например, я не вижу другого «магазина приложений», кроме Ubuntu. Если кто-то хочет поддерживать такой пакет, меня это устраивает, но по указанным выше причинам это буду не я.

Другой вариант - Flatpak, который лично мне кажется более интересным, чем Snappy, не в последнюю очередь из-за его интеграции в Gnome Software.

Да, я согласен с @phw , это, вероятно, самая большая проблема Snappy, несмотря на усилия Ubuntu, он все еще, как ни странно, тоже Ubuntu-y.

Также я думаю, что цель этих новых усилий состояла в том, чтобы попытаться сделать их достаточно простыми универсальными системами упаковки, чтобы разработчики сами могли упаковать и исключить посредников, но я думаю, что если у вас действительно нет времени на упаковку, тогда это может '' не помочь.

@phw не уверен на 100%, но undefined symbol: hb_buffer_set_cluster_level похоже на проблему с вашей базовой системой; см. http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

В остальном мне нравится идея, а также автоматическое построение с помощью Трэвиса.

Если вы хотите пойти по этому пути, вам не нужна упаковка deb для создания AppImage. Примеры:
https://github.com/search?q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22&type=Code&utf8=%E2%9C%93

Можно ли было бы также предложить 32-битную (возможно, мне потребуется изучить 32-битную кросс-компиляцию, чего я до сих пор избегал). Если бы вы могли предоставить для этого пул-реквест, было бы здорово.

Я мало исследовал эту область, но это определенно выполнимо; проект MuseScore предоставляет AppImages для x86_64, i686 и armhf (например, Raspberry Pi).

Моя основная проблема со всей упаковкой заключается в том, что я не хочу делать это сам и что при выпуске нужно приложить минимум усилий.

AppImage создан с учетом этого варианта использования ... :)

По крайней мере, наличие PPA было бы тем, что я знаю, как это сделать.

Затем вы можете использовать что-то вроде рецепта, который я опубликовал выше, для преобразования debs из (в идеале надежного или более старого) ppa в AppImage в основном автоматически.

По крайней мере, наличие PPA было бы тем, что я знаю, как это сделать.

Затем вы можете использовать что-то вроде рецепта, который я опубликовал выше, для преобразования debs из (в идеале надежного или более старого) ppa в AppImage в основном автоматически.

Это также возможный план для 32-битной сборки. Вероятно, проще настроить PPA (получение 32-битных сборок бесплатно), чем добавить кросс-компиляцию в сборку CMake.

@phw не уверен на 100%, но не определен символ: hb_buffer_set_cluster_level кажется проблемой в вашей базовой системе; см. http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

Я скорее подозреваю, что что-то не так с библиотеками, против которых это было построено, так как у меня очень свежие и обычно неизмененные версии всех библиотек в моей системе. Я часто ставлю на то, что произойдет какое-то исправление Debian / Ubuntu :)

Из вашего рецепта мне не совсем понятно, как и откуда бинарные файлы Peek для AppImage. Это что-то указано при создании финального изображения AppImage из рецепта?

Из вашего рецепта мне не совсем понятно, как и откуда бинарные файлы Peek для AppImage. Это что-то указано при создании финального изображения AppImage из рецепта?

Скрипт, запускающий рецепт, находится по адресу https://github.com/probonopd/AppImages/blob/master/recipes/meta/Recipe.

Что насчет этого репозитория OBS Ubuntu ? Кто его поддерживает, и является ли оно «официальным»? Я связался с Эндрю с webupd8.org, чтобы предоставить PPA для Peek. Если этот OBS больше не поддерживается, Эндрю может помочь.

Я думаю, что это тот, который упомянул пользователь по адресу:
http://www.omgubuntu.co.uk/2016/08/peek-desktop-gif-screen-recorder-linux#comment -2894366969

Не похоже, что он хочет управлять этим, но я могу попросить его предоставить мне доступ или, по крайней мере, используемую конфигурацию. OBS будет иметь то преимущество, что его можно будет построить и для других систем. С другой стороны, я обнаружил, что использовать OBS в последний раз было немного неприятно.

Тебе решать. Как я уже сказал, если вы предпочитаете PPA, Эндрю может помочь ;-)

@phw

Я могу встроить функцию просмотра в свой собственный PPA. Но чтобы сделать это правильно, вам нужно правильно настроить его на панели запуска, чтобы вам не приходилось его поддерживать. Он будет автоматически компилироваться при обнаружении новых изменений.

1. Сначала создайте новый проект на панели запуска с именем «Peek» . Создайте PPA (названный "peek-daily") в рамках проекта.

1. В разделе проект-> код выберите импорт. Выберите цель и источник как git. Дайте имя основной ветви (например, ствол ). Очевидно, владелец должен быть самим собой

2. 

3. Создайте новое репо «Peek-Packaging» на GitHub, которое должно содержать только папку debian (вы можете скопировать из репозитория OBS)

4. Импортируйте репо упаковки таким же образом, как и основное репо. Дайте любое имя во время импорта, например "debian-packages"

5. Перейдите в Project (т.е. загляните) -> code-> просмотрите репозитории git. Нажмите lp:~USERNAME/kee/+git/trunk . Затем нажмите create a packaging recipe .

6. Дайте рецепту название. Выберите свой собственный PPA и проверьте серию рассылки. (пикантность, ксениал ... и т. д.)

7. Теперь о содержании рецепта. Должно получиться так:

# 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. Сохраните его и нажмите «Запросить сборку». Он начнет создавать ваш код! На наличие ошибок проверьте журналы сборки. Не путайте с названием «build-daily». Он строится только тогда, когда обнаруживает какие-либо изменения в основном репозитории или репозитории упаковки.

2. СДЕЛАННЫЙ!

Он будет импортировать только основную ветку. Вы можете использовать отдельную ветку для релизов. Во время создания рецепта вы можете использовать эту конкретную ветку вместо ствола.

Хорошо, мы к чему-то приближаемся :) Наконец-то я начал это делать, теперь PPA для ежедневной сборки доступен по адресу:

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

Код построен по следующему рецепту: https://code.launchpad.net/~peek-developers/+recipe/peek-daily
Информация об упаковке фактически находится в сиротской ветке в основном репозитории Peek git, см. Https://github.com/phw/peek/tree/debian-packaging

Я был бы признателен, если бы у кого-нибудь был ткацкий станок и он дал мне обратную связь, так как прошло очень много времени с тех пор, как я возился с упаковкой Debian и PPA Launchpad, а пользовательский интерфейс Launchpad ужасен.

@phw, с того места, где я сижу, это действительно просто и хорошо работает. Спасибо.

$ 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 Прекрасно работает. Благодарю.

@phw можно ли добавить надежный и / или точный в ppa?
Благодарю.

@probonopd Trusty в настоящее время не работает из-за версии GTK, но я все равно хочу снизить требуемую версию, см. №54.

Если это исправит сборку и для Precise, я позволю ей также построить там. В противном случае я не стал бы возиться с Precise, потому что его жизнь неизбежна.

Согласен

@probonopd Я попытался выполнить эту работу для Trust, но решил, что сборок для trusty не будет, Peek использует слишком много функций, которые недоступны в Gtk 3.10 и версиях glib и gio, которые предоставляет trusty, и потребуют обходных путей или получения отключен, и это будет для меня слишком много для поддержки.

@probonopd Есть ли способ обойти это с помощью AppImage, или Peek слишком интегрирован с остальной системой, чтобы это было возможно (т.е. если вы связали свой собственный GTK в AppImage и / или я сделал в Snap, то это могло работать?)

Изменить: Да, вы сказали, что это работает с дистрибутивами 2014+?

@ Ads20000, который собирает AppImage, может решить, что связать и что использовать из целевой системы (систем). Проект peek может решить объединить Gtk 3.10 и версии glib и gio, необходимые для peek, в качестве частных копий внутри AppImage. Тем не менее, Gtk 3.10, glib и gio должны быть скомпилированы на самых старых системах, на которых они еще могут быть скомпилированы, чтобы не использовать последние версии glibc и т. Д. В результате получился бы AppImage большего размера, который по-прежнему работал бы в старых дистрибутивах.

@probonopd Нет, я имел в виду, может ли Peek связать более новую версию GTK (чем 3.10) внутри AppImage, чтобы заставить ее работать на старых дистрибутивах ??

@ Ads20000 Да, если более новая версия GTK (чем 3.10) будет скомпилирована на более раннем дистрибутиве.

Хорошо, теперь это работает. Я обновил README.

Сейчас есть два PPA, один для ежедневных сборок, а другой для стабильных выпусков:

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