Comments (32)
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.
from peek.
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.
from peek.
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 :)
from peek.
Yes indeed, you can browse this page to see the latest releases: Releases. There's even an atom feed you can watch!
from peek.
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").
from peek.
@phw would it be possible to add trusty and/or precise to the ppa?
Thanks.
from peek.
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
from peek.
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.
from peek.
And the next version of Peek will give you a "--version" command line parameter, so you can easily compare your local version.
from peek.
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
from peek.
@Ads20000 Check AppImageUpdate.
from peek.
@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.
from peek.
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.
from peek.
Yes I agree @phw that's probably Snappy's biggest problem, despite Ubuntu's efforts it's still, funnily enough, too Ubuntu-y.
from peek.
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.
from peek.
@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
from peek.
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.
from peek.
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?
from peek.
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
from peek.
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.
from peek.
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.
from peek.
It's up to you to decide. As I said, If you prefer a PPA, Andrew may help ;-)
from peek.
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.
-
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
-
Create a new repo "Peek-Packaging" at GitHub which must contain only the debian folder (you can copy from the OBS repo)
-
Import the packaging repo in the same manner as the main repo. Give any name during the import like "debian-packaging"
-
Go to Project (i.e peek)-> code-> view git repositories. Click on
lp:~USERNAME/kee/+git/trunk
. Then click oncreate a packaging recipe
. -
Give a recipe name. Select your own PPA & check distribution series. (zesty, xenial...etc)
-
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
-
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.
-
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.
from peek.
@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) ...
from peek.
@phw Working wonderfully well. Thanks.
from peek.
@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.
from peek.
Agree
from peek.
@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.
from peek.
@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?
from peek.
@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.
from peek.
@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??
from peek.
@Ads20000 Yes, as long as the newer version of GTK (than 3.10) would be compiled on an older distribution.
from peek.
Related Issues (20)
- error
- failed with status 256 (received signal 0). HOT 1
- Error - Record as GIF HOT 1
- Error while recording screen: "GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying"
- Profile Achievement Suggestion: Versatile HOT 2
- Recording stopped HOT 1
- Error when trying to record any type 😢 HOT 1
- PopOS! 22.04 - Peek is not saving to GIF - Timeout was reached HOT 1
- Recording error
- Can't Record GIF
- Peek times out when trying to save a recording
- GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code19: Invalid params
- I can't save record on Pop!OS
- Timeout recording error
- Troubles to save GIF on PoP!_OS
- Can't record video out
- Timeout was reached
- Recording fails on PopOS
- Does not save video
- not working
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from peek.