Add Peek to a PPA

[quentin-st]

This would allow us to update Peek without having to re-download its deb installer on every release.

[phw]

Absolutely, I would very much like to see this. But at least at the moment it is unrealistic that I will be able to maintain the PPA and keep it up to date, so I would need some help here. If anybody can set this up it would be awesome :)

[matheusgeres]

Is it possible to verify if a new version has released? It's a good idea to see when something new is released and I think it's possible to run something like 'dpkg -i' to install it.

[quentin-st]

Yes indeed, you can browse this page to see the latest releases: Releases. There's even an atom feed you can watch!

[phw]

And the next version of Peek will give you a "--version" command line parameter, so you can easily compare your local version.

[Ads20000]

Could I suggest skipping the PPA stage and going straight to packaging with Snappy (with a probably out-of-date DEB in the official repositories for those who want it)? I think one of the points of Snappy is to end the necessity for people to have to add lots of PPAs to keep packages up-to-date more than the default repositories do. All you have to do is make a Snap and then upload it to the official store and voila, Ubuntu users (as well as Arch and Debian Unstable users, and Fedora, Gentoo and OpenSUSE users with the Snappy repository enabled) have up-to-date Peek. I don't think it's too hard to keep a Snap updated once it's made.

[probonopd]

How about an AppImage? I have uploaded an experimental one to https://bintray.com/probono/AppImages/Peek/_latestVersion#files Just download the AppImage, make it executable, and run. The GIF below was made with it :-)

Should run on 2014ish or later distributions. Some rough edges expected, testing and polishing might be needed.

@phw let me know if you are interested in this. If yes, I can extend your existing .travis.yml so that a fresh, continuous AppImage is produced on each build. (The AppImage above was made from debs using this recipe, but I understand you are looking for something more "agile").

[Ads20000]

Great job @probonopd (I'm not a contributor here but well done for getting it done)! The more package formats the better (as long as they're fairly low maintenance, and formats like Snappy and AppImage I think usually are once you've got the initial implementation done), I do think that Snappy is better though because they automatically update.

I had a look at trying to get Spotify Web Player for Linux (another FOSS application) bundled into a Snap but it might be more work than I thought to snap applications...great AppImage is so easy

[probonopd]

@Ads20000 Check AppImageUpdate.

[Ads20000]

@probonopd That's good but that doesn't look very automatic (it is decentralised, after all)? I quite like the Snappy system where although the default store is the Ubuntu one (which makes it quite centralised), it is possible to set up an alternative app store.

Oh, you are the creator/maintainer of AppImageKit, didn't realise! Well like I say, properly automatic updating I think is probably necessary if you want this to become the dominant format. Also the capability to use libraries that are already on the system or in other AppImages (only if they're the same version) to bring down file size? If they could be intelligent and use parts of libraries in other versions which are the same then that would be even cooler.

[phw]

Thanks @probonopd for that AppImage. The recipe looks simple enough, and it is easy to run. Unfortunately that AppImage you made does not run on my Arch installation and upon executing it fails with:

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

Otherwise I like the idea, also of building it automatically with travis. Would it be possible to also offer a 32 bit one (probably requires me to look into the 32 bit cross-compiling, something I have avoided so far). If you could provide a pull request for this it would be great.

My main issue with all the packaging is, that I don't want to do it myself and that it should make a minimum of effort when releasing, as I have problems finding the time for development anyway. Having a PPA would at least have been something I know how to do, but as I don't use Ubuntu myself it is hard to keep up with all different versions (I know, since I am kind of maintaining the PPA for another project and have to look into strange build errors frequently when new Ubuntu versions become available).

Snappy images sound interesting, but they are to me (despite all claims) very Ubuntu specific. E.g. I don't see any other "app store" despite the Ubuntu one. If somebody wants to maintain such a package I am fine with it, but for the above reasons it will not be me.

Another option would be Flatpak, which I personally find more interesting than Snappy, not least because of its integration into Gnome Software.

[Ads20000]

Yes I agree @phw that's probably Snappy's biggest problem, despite Ubuntu's efforts it's still, funnily enough, too Ubuntu-y.

[Ads20000]

Also I think the purpose of these new efforts was to try and make them easy enough universal packaging systems that the developers themselves could package and cut out the middleman, but I guess if you don't really have the time to package then that can't be helped.

[probonopd]

@phw not 100% sure but undefined symbol: hb_buffer_set_cluster_level seems like an issue with your base system; see http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

[probonopd]

Otherwise I like the idea, also of building it automatically with travis.

If you want to go this route then you don't need deb packaging to produce an AppImage. Examples: https://github.com/search?q=%22Package+the+binaries+built+on+Travis-CI+as+an+AppImage%22&type=Code&utf8=%E2%9C%93

Would it be possible to also offer a 32 bit one (probably requires me to look into the 32 bit cross-compiling, something I have avoided so far). If you could provide a pull request for this it would be great.

I haven't investigated this area much but it's definitely doable; the MuseScore project provides AppImages for x86_64, i686, and armhf (e.g., Raspberry Pi).

My main issue with all the packaging is, that I don't want to do it myself and that it should make a minimum of effort when releasing

AppImage is made with this use case in mind... :)

Having a PPA would at least have been something I know how to do

Then you can use something like the recipe I posted above to convert debs in the (ideally trusty or older) ppa to an AppImage mostly automatically.

[phw]

Having a PPA would at least have been something I know how to do

Then you can use something like the recipe I posted above to convert debs in the (ideally trusty or older) ppa to an AppImage mostly automatically.

That's also a possible plan for having the 32 bit build. It is probably easier to setup the PPA (getting 32 bit builds for free) then to add the cross compiling to the CMake build.

@phw not 100% sure but undefined symbol: hb_buffer_set_cluster_level seems like an issue with your base system; see http://unix.stackexchange.com/questions/235012/problem-with-gtk-application-s

I rather suspect something wrong with the libraries where this was build against, as I have very recent and usually unmodified versions of all the libraries on my system. My bet is often on some Debian / Ubuntu patching happening :)

From your recipe it is not entirely clear to me how and from where the Peek binaries for the AppImage are obtained. Is it something specified when creating the final AppImage from the recipe?

[probonopd]

From your recipe it is not entirely clear to me how and from where the Peek binaries for the AppImage are obtained. Is it something specified when creating the final AppImage from the recipe?

The script that runs the recipe is at https://github.com/probonopd/AppImages/blob/master/recipes/meta/Recipe

[mohamedsakhri]

What about this OBS Ubuntu repository? Who is maintaining it and is it "official"? I contacted Andrew from webupd8.org to provide and maintain a PPA for Peek. If this OBS isn't maintained anymore, Andrew could help.

[phw]

I think that's the one mentioned by the user at: http://www.omgubuntu.co.uk/2016/08/peek-desktop-gif-screen-recorder-linux#comment-2894366969

Doesn't look like he wants to manage it, but I could ask him to give me access or at least the configuration used. OBS would have the benefit that it could also build for other systems. On the other hand I found OBS to be a bit unpleasant to use the last time I tried.

[mohamedsakhri]

It's up to you to decide. As I said, If you prefer a PPA, Andrew may help ;-)

[khurshid-alam]

@phw

I can build peek into my own PPA. But to do it properly you need to set it up properly on launchpad so that you don't have to maintain it. It will compile automatically when it detect new changes.

1, First create a new project on launchpad named "Peek". Create a PPA (named "peek-daily") under the project.

2. Under project->code select import. Select target and source both as git. Give a name to the main branch (for example: trunk). Obviously owner should be yourself

3. 

4. Create a new repo "Peek-Packaging" at GitHub which must contain only the debian folder (you can copy from the OBS repo)

5. Import the packaging repo in the same manner as the main repo. Give any name during the import like "debian-packaging"

6. Go to Project (i.e peek)-> code-> view git repositories. Click on lp:~USERNAME/kee/+git/trunk. Then click on create a packaging recipe.

7. Give a recipe name. Select your own PPA & check distribution series. (zesty, xenial...etc)

8. Now the recipe contents. It should look like this:

# 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

9. Save it and click on "Request Build". It will start building your code! For errors check the build-logs. Don't get confused with the name "build-daily". It only builds when it detects any changes in the main or the packaging repo.

10. DONE!

It will only import master branch. You can use use separate branch for releases. During recipe creation you can use that particular branch instead of trunk.

[phw]

Ok, we are getting somewhere :) I have finally started get this going, there is now a daily build PPA at:

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

The code is built using this recipe: https://code.launchpad.net/~peek-developers/+recipe/peek-daily The packaging information is actually in an orphan branch in the main Peek git repository, see https://github.com/phw/peek/tree/debian-packaging

I would appreciate if somebody could have a loom at this and give me some feedback, since it has been a very long time since I fiddled with Debian packaging and Launchpad PPAs, and the Launchpad UI is horrible.

[anavarre]

@phw from where I sit this is really straight forward and works well. Thank you.

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

[khurshid-alam]

@phw Working wonderfully well. Thanks.

[probonopd]

@phw would it be possible to add trusty and/or precise to the ppa? Thanks.

[phw]

@probonopd Trusty is currently failing due to GTK version, but I want to lower the required version anyway, see #54.

If that fixes the build also for Precise I will let it also build there. Otherwise I won't bother with Precise since it's end of life is imminent.

[probonopd]

Agree

[phw]

@probonopd I tried to get this work for Trust, but I have decided there will be no builds for trusty, Peek is using too many features that are not available in Gtk 3.10 and the glib and gio versions trusty provides and would require workarounds or getting disabled, and this will be too much for me to support.

[Ads20000]

@probonopd Is there any way to work around this with AppImage or is Peek a bit too integrated with the rest of the system for that to be possible (i.e. if you bundled your own GTK in the AppImage and/or I did in the Snap then it could work?)

Edit: Yes you said you got this working on 2014+ distros?

[probonopd]

@Ads20000 who puts together the AppImage can decide what to bundle, and what to use from the target system(s). The peek project could decide to bundle Gtk 3.10 and the glib and gio versions required by peek as private copies inside the AppImage. Still Gtk 3.10, glib and gio should be compiled on the oldest systems they still can be compiled on, in order not to draw in the latest glibc etc. versions. The result would be a bigger AppImage that still would work on older distributions.

[Ads20000]

@probonopd No I meant could Peek bundle a newer version of GTK (than 3.10) inside the AppImage to get it to work on older distros??

[probonopd]

@Ads20000 Yes, as long as the newer version of GTK (than 3.10) would be compiled on an older distribution.

[phw]

Ok, this seems to work now. I have updated the README.

There are two PPAs now, one with daily builds and one for stable releases:

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