Comments (63)
Providing an AppImage would have, among others, these advantages:
- Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
- One app = one file = super simple for users: just download one AppImage file, make it executable, and run
- No unpacking or installation necessary
- No root needed
- No system libraries changed
- Works out of the box, no installation of runtimes needed
- Optional desktop integration with
appimaged
- Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
- Can optionally GPG2-sign your AppImages (inside the file)
- Works on Live ISOs
- Can use the same AppImages when dual-booting multiple distributions
Here is an overview of projects that are already distributing upstream-provided, official AppImages.
from bookworm.
yes a few others have asked if it can be made distro agnostic...I will definitely try to do that once all the features and format support for Bookworm are done
This is great news. Thank you for being supportive to other operating systems.
If you want you can try installing the PPA on Solus and add a screen shot here...that will give me some idea on how much work is needed for making Bookworm distro agnostic
Solus is not Ubuntu-based but a completely independent operating system. The easiest for me (and for many others coming from non-Ubuntu distros) is probably if you add a Flatpak (http://flatpak.org/) or AppImage (http://appimage.org/) to your GitHub releases. This would significantly increase feedback to your application as users unable to compile from source will be able to report bugs and raise feature requests.
from bookworm.
@baimafeima thanks for the update. I have played around with snap for my other app (Nutty). Have not looked at Flatpak yet, will do so when I have a logical completion point in Bookworm
from bookworm.
Yes, it can be set up to build new AppImages on GitHub every time you git push
. Many examples on how to do this are listed at https://github.com/probonopd/linuxdeployqt#projects-using-linuxdeployqt.
Alternatively you can use the Open Build Service, described at https://git.io/obs-ai. That way, your AppImage would get rebuilt even if one of its ingredient depdendencies gets updated.
from bookworm.
Thanks let me give it a go...will let you know how it went
from bookworm.
ok...will try to find a PPA for libgranite 0.1.0 and try a launchpad build...will update back here shortly...thanks a lot for your time and help...
from bookworm.
@baimafeima good pointer. No use getting compatibility for webkit1. Unfortunately it looks like AppImage needs to be webkit1 compatible so will not be building bookworm as a AppImage. I have anyways got bookworm as a Flatpak for cross distro installation.
from bookworm.
A quick google seems you are correct:
http://doc.qt.io/archives/qt-5.5/qtwebkitexamples-index.html
Based on the above hopefully we should be fine for bookworm as AppImage...next steps on how to set up a AppImage build on Travis?
from bookworm.
Thanks for opening this issue...yes a few others have asked if it can be made distro agnostic...I will definitely try to do that once all the features and format support for Bookworm are done (will take me quite a while though)...
I think the current code should work on all ubuntu based systems. Only the elementary granite and CSS will look different. Also the images/icon of elementary that I have used may not find equivalents on other distros...The workaround will be to put in a little code to include those icons with the code package so that it does not need to find them from the distro....
If you want you can try installing the PPA on Solus and add a screen shot here...that will give me some idea on how much work is needed for making Bookworm distro agnostic...hopefully the install will go fine...
sudo add-apt-repository ppa:bookworm-team/bookworm
sudo apt-get update
sudo apt-get install bookworm
from bookworm.
Glad to see supporting Linux distributions other than eOS is on the way. There are, for example, more than 20 million Ubuntu desktop users, and I reckon a good % would love to be able to use this app because there's little else like it available.
With Ubuntu switching back to upstream GNOME it might be worth using cross-distro standards rather than those only available on Elementary.
Great work 👏
from bookworm.
@probonopd Thanks for this suggestion...AppImage looks promising - will read up on the same to see how I can set it up for bookworm. Hopefully there is integration with GitHub to build automatically when updates are made or a release is made...
from bookworm.
@probonopd I have got TravisCI working with this .travis.yml file....
Should I just add the additional content from the linuxdeployqt file in the example ?
from bookworm.
Yes, but make sure to replace APPNAME two times. Let me know how it goes. Alternatively, I can do it real quick for you.
from bookworm.
@probonopd
I might have missed something, the travis build failed with:
$ ./linuxdeployqt*.AppImage ./appdir/usr/share/applications/.desktop -bundle-non-qt-libs
Desktop file as first argument: "./appdir/usr/share/applications/.desktop"
desktopExecEntry: "r"
desktopIconEntry: "r"
ERROR: Could not determine the path to the executable based on the desktop file
from bookworm.
The real error must be earlier... yes:
This application needs you to use cmake
rather than qmake
, that is
- cmake . -DCMAKE_INSTALL_PREFIX=/usr
- make -j$(nproc)
- make DESTDIR=appdir install ; find appdir/
instead of
- qmake PREFIX=/usr
- make -j$(nproc)
- make INSTALL_ROOT=appdir install ; find appdir/
from bookworm.
Also make sure that the DEPENDENCY_PACKAGES
get installed (outside of the Docker containers if you are not using them for the AppImage) in .travis.yml
.
from bookworm.
@probonopd many thanks for the pointers...
I'm not sure how to represent the DEPENDENCY_PACKAGES outside of the docker container...these packages are used for building the app - so not sure if those packages are needed for the AppImage...
Also how do I represent the utilities like unrar, unzip, etc. which are required by bookworm to run...
from bookworm.
Since you are building the app for AppImage outside of the Docker container, you need to install the build dependencies outside of the Docker container, too.
Does the app really use the command line tools or just the libraries for the package formats? You would also have to bundle the unrar
, unzip
, etc. command line tools by copying them into the AppDir, along with their respective dependencies. There is currently no automated way to do this. In the latter case (if the app uses libraries rather than command line tools, as it probably should), linuxdeployqt
will handle them automatically for you.
from bookworm.
@probonopd
For installing dependencies outside of docker, do you have an example of how I should do it?
The app uses the command line tools for unrar, unzip, etc rather than libraries of the same. For copying them to the AppDir, should I add something to the "after_success" ...i.e. "cp unzip appimage/"...where would the source be for these command line utilities...can do with your help here
from bookworm.
@babluboy can you or any of the core devs confirm that this app can be built on Ubuntu trusty 14.04? Then I will give it a try.
from bookworm.
@probonopd I'm the only dev for this app :-) ...I dont think it can be built on Ubuntu Trusty 14.04...
Just started a build on Launchpad for Trusty here, will update back in a couple of minutes...
from bookworm.
@probonopd As expected the build failed on Trusty due to an issue with "libgranite-dev"
E: Build-Depends dependency for bookworm cannot be satisfied because candidate version of package libgranite-dev can't satisfy version requirements
Build log here
from bookworm.
Please ask the developers of libgranite-dev
for a trusty ppa and use that for the build, or change the source code so that 0.1.0 (the version in trusty universe) is sufficient.
from bookworm.
@probonopd Since the app uses some granite widgets for look and feel and is primarily targeted at elementary OS, i would have to check if I can remove the granite dependency. I will also check if libgranite can be made available for Trusty....guess AppImage is dependent on the app being built successfully for Trusty...
from bookworm.
libgranite 0.1.0 is available for trusty. If you can make your app compile against that version, then it shall work.
from bookworm.
No ppa needed:
https://packages.ubuntu.com/trusty/libdevel/libgranite-dev
from bookworm.
@probonopd Yes, I managed to get over the libgranite-dev issue, but got stuck with webkit.
Trusty needs libwebkit2gtk-3.0-25 while Xenial needs libwebkit2gtk-4.0-37, so I tried the following in the debian control
libwebkit2gtk-3.0-25 | libwebkit2gtk-4.0-37,
libwebkit2gtk-3.0-dev | libwebkit2gtk-4.0-dev,
However, the build failed on Trusty as it is looking for the libwebkit2gtk-4.0
Not sure how to make libwebkit2gtk-4.0 optional in the debian control.
Any ideas on how to progress ?
from bookworm.
Build fails with
-- checking for modules 'gtk+-3.0;gee-0.8;granite;webkit2gtk-4.0>=2.16.0;sqlite3>=3.5.9;poppler-glib'
-- package 'webkit2gtk-4.0>=2.16.0' not found
CMake Error at /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:283 (message):
A required package was not found
So I guess that the CMakeLists.txt
(and possibly, the source code) needs to be edited to allow for a lower version (not the debian control file).
from bookworm.
@probonopd You were right, the CMakeLists.txt was indeed the culprit and I did the following to get the application to compile:
1- Created a trusty VM and installed libwebkit2gtk-3.0-25, libwebkit2gtk-3.0-25
2- Updated the CMakeLists.txt to create conditional package lists for trusty and xenial (attached)
3- Added the webkitgtk-3.0.vapi (attached) to /usr/share/vala-0.22/vapi/ and added a vapidir to CmakeLists
The above allowed me to compile the application, but looks like gtk3 does not have the key API which bookworm uses:
error: The type name `WebKit.Settings' could not be found
error: The type name `WebKit.ContextMenuItem' could not be found
error: The type name `WebKit.NavigationPolicyDecision' could not be found
error: The type name `WebKit.NavigationAction' could not be found
error: The type name `WebKit.URIRequest' could not be found
I'm thinking that the vapi I picked up has not been compiled against webkit2 and hence the above errors. Will check further on how to create a vapi file against webkit2
Trusty CMakeLists_webkit3vapi.zip
from bookworm.
I was able to generate the vapi using:
sudo apt install gir1.2-webkit-3.0
vapigen --library webkitgtk-3.0 --pkg gio-2.0 --pkg gtk+-3.0 /usr/share/gir-1.0/WebKit2-3.0.gir
Using the vapi created above resolved most of the webkit errors but others like the below are still there (attached):
error: The type name `WebKit.NavigationAction' could not be found
error: The type name `Gtk.Popover' could not be found
At this point I'm giving up on trying to compile Bookworm on Trusty. Hopefully when AppImage can work on Xenial builds, I will be able to progress the issue.
Let me know if you see any other way forward.
from bookworm.
Sure, you can put into an AppImage whatever you like. But if you put in something that was built on Xenial, it will not run on distributions older than Xenial. Since Trusty is currently the oldest still-supported LTS version, that's what we currently recommend to target (and require for inclusion in the AppImageHub directory of available AppImages).
Generally speaking, i find it surprising that application developers frequently develop against the latest and greatest APIs and then seem surprised when applications don't work on any but the latest OSes...
from bookworm.
@probonopd Agree with your thoughts, however when I started with Bookworm I didnt have other distros in mind and used the version of elementary OS (Loki) as the base for the development. Probably I should have tried using older libraries for the design but then there is the danger of having the API deprecated as webkit 1 is pretty old now...so I started with webkit 2
Anyways, would you be able to assist me in correcting the dependencies in the current travis.yaml (DEPENDENCY_PACKAGES outside of the docker container) and how to add the utilities like unrar, unzip, etc. (which are required by bookworm to run) into the travis.yaml
from bookworm.
Well, as a first step I think moving from using command line tools as dependencies to using the underlying libraries would be a good first step to make the application more robust and much easier to deploy, what do you think?
from bookworm.
@probonopd yes using libraries rather than the dropping to execute command line gives more control and error handling capabilities and I will make it a goal....so if AppImage does not work with dependent executables for the meantime...we can keep this on hold...i will try snaps and flatpak to see if they work with bookworm in the current format...
from bookworm.
I didn't say AppImage would not work with bookworm in the current format. Of course you can put dependent executables (and their dependencies) into the AppImage, and there are many apps that do. If you put them into usr/bin
and usr/lib
respectively, and use the default AppRun
from AppImageKit, then they will be picked up from there automatically.
from bookworm.
@probonopd oops my bad...didn't know that executables could be included in the appimage....rather than building the appimage on my laptop, is there a sample travis.yaml which shows how to include those binary dependencies...if I can get the appimage to build on travis then it can be automated with push to GitHub
from bookworm.
Please ping me once it builds on trusty, then I'll have a look at it.
from bookworm.
@probonopd No bookworm is not backwards compatible with Trusty due to the dependence on Webkit2.
Will it be possible to achieve the travis build to create an AppImage for Bookworm in the current format with Xenial and upwards compatibility with the ability to package required binaries?
from bookworm.
Yes, it would be possible to achieve the travis build to create an AppImage for Bookworm in the current format with Xenial and upwards compatibility with the ability to package required binaries. But if you use Xenial ingredients for the AppImage, then the AppImage will only run on very new distributions (e.g., not on Debian stable or CentOS). This is why I recommend to "backport" it first.
from bookworm.
@probonopd agree with your thoughts however it will be a substantial effort to write additional functions into WebKit1 which is already available in webkit2....
So I was thinking to get an appimage out first...to provide a install mechanism for distros supporting Xenial and up...will allow me to learn Appimage as well...and then see later if it's worth the effort to go back to webkit1...
from bookworm.
WebKit1
will soon - at least for Solus - be deprecated: https://dev.solus-project.com/T4880
I don't think it's valuable to go back to it.
from bookworm.
Unfortunately it looks like AppImage needs to be webkit1 compatible so will not be building bookworm as a AppImage.
What makes you think that?
I have anyways got bookworm as a Flatpak for cross distro installation.
The point with AppImages is that they need no installation and are "one app = one file".
from bookworm.
@probonopd apologies...what I wanted to say was based on your comment here to backport to older versions like Trusty, it would require me to backport the code to use Webkit1 (since Webkit2 is not available for Trusty). It would be too much effort to backport to webkit1 when it is already fated...
If you can help me get bookworm in its current form (Xenial and upwards) into AppImage then I will be grateful...as I could not do it myself after giving it a try...
from bookworm.
Qt 5.10 (the very latest one) from qt.io runs on Trusty. Would that not be sufficient to build bookworm?
from bookworm.
As I said Bookworm will not build on Trusty (due to unavailability of WebKit2)...however if you are able to get Qt 5.10 work to build a AppImage it will be great....
from bookworm.
What do you mean by "WebKit2" - isn't that a component of Qt? I have to admit that I am somewhat confused by the different "Web*" components of Qt these days.
from bookworm.
Basically you should be able to use the Travis CI example from the linuxdeployqt
GitHub page.
from bookworm.
@probonopd The application depends on webkit2gtk, which is the gtk port of the webkit engine(similar to qtwebkit, which is the QT counterpart). Looking at the Cmakelists file, it looks like it depends on webkit2gtk-4.0>=2.16.0
, which IIRC is not available in Trusty, even in a PPA. Rest of the dependencies can be managed I think.
There used to be a Webkit stable ppa, which is not updated any more.
P.S. If I wan't clear, there is no QT involved here, so I don't know how that matters.
from bookworm.
Ah, sorry, I somehow was assuming this to be a Qt application. In any case, linuxdeployqt generally works on non-Qt apps too, so the "only" issue is where to get webkit2gtk for Trusty from.
from bookworm.
I think, yes. What do you think @babluboy ? Will this build with older versions of Gtk+ and Granite, if there is a compatible webkit2gtk version available on Trusty?
from bookworm.
I agree - if we can find a version of webkit2gtk and granite0.5 on Trusty then Bookworm can build on Trusty....though I think that's not possible.
Here are the Ubuntu Releases which support webkit2gtk and as expected it is Xenial and up:
https://packages.ubuntu.com/search?searchon=sourcenames&keywords=webkit2gtk
Can we conclude then that AppImage in its current stage will not support Bookworm?
from bookworm.
@babluboy You can still create an AppImage, but it will only work on Xenial and up. TBH I'm happy with how Flatpak works, so I will probably not use it. However, plenty of people on modern OSs who don't want to install Flatpak will definitely appreciate it I think :)
from bookworm.
Can we conclude then that AppImage in its current stage will not support Bookworm?
No. We can conclude that Bookworm in its current stage will not support the oldest still-supported Ubuntu LTS release, which at this point is 14.04 (trusty).
AppImage is just a self-mounting filesystem. AppImage does not determine which versions a set of binaries do, or do not, support. The situation would be exactly the same if you would distribute the binaries, say, as a zip file.
from bookworm.
Agree. Hoping there might be people who will still benefit from an AppImage for Xenial and up. I have updated the .travis.yml with the linuxdeployqt script as suggested.
However, the build on Travis has failed, can you please take a look at the Travis build log here and suggest tweaking of the yml script.
from bookworm.
You need to use trusty, not xenial, if you want to install that Qt.
from bookworm.
ok...let me make that change and see if it succeeds, hopefully it wont hit other webkit2gtk dependency issues.
from bookworm.
Still failed with the same error: https://travis-ci.org/babluboy/bookworm/builds/331154760?utm_source=email&utm_medium=notification
Any chance you can take a look at the travis.yml and submit a PR ? I am not that conversant with AppImage and might make some mistakes which might be silly for you :-)
from bookworm.
You are now trying to install packages from precise ppas? As a rule of thumb, you can only install ppas for the version of the OS that you are using.
Any chance you can take a look at the travis.yml and submit a PR
Due to time constraints, I am currently focusing on software that is supported on all supported versions of Ubuntu reaching back to the oldest still-supported LTS release.
from bookworm.
Well it looks like a catch 22: linuxdeployqt will not work without Trusty and Bookworm will not work on Trusty (due to dependencies not available in Trusty).
Appreciate you are busy with other work, I will revert back the .travis file until the time you or some else can figure out how to build an AppImage for Bookworm using Travis builds
from bookworm.
Is there an appimage of bookworm (even an experimental one) by now?
from bookworm.
Since the application cannot be compiled on the oldest still-supported version of Ubuntu according to @babluboy it is currently not possible to produce an AppImage that would run on all still-supported versions of Ubuntu, at least not without bundling everything.
Bookworm will not work on Trusty (due to dependencies not available in Trusty).
from bookworm.
Well, you can easily note the supported distributions by the appimage below the download-link or even add that info to the appimage-filename:
bookwork-1.1.0-Xerus-to-Cuttlefish.appImage
from bookworm.
It's a matter of which distributions to a developer wants to target. I am encouraging developers to develop against all still-supported Linux distribution releases rather than just targeting the latest and greatest. Similar, on the Mac it is not a good idea to assume everyone is running the latest version of the OS. Likewise, on Windows.
Of course the author of an application who makes an AppImage can decide what to put inside. If a developer wants to target only newer distributions, that's entirely fine.
The only caveats are:
- My tools are not tested on anything but the oldest still-supported Ubuntu LTS release, which currently is 14.04 (trusty)
- https://appimage.github.io/ runs all submitted AppImages through an automated test on the oldest still-supported Ubuntu LTS release; if that test does not pass the application cannot be added to the directory
from bookworm.
Related Issues (20)
- Appstream complains about the image HOT 2
- suggestion: use a different/additional call sign for the CLI
- suggest: update webpage re Python HOT 1
- Can't change colors with "Customize reading profile" options HOT 1
- Two page reading layout problem
- Runtime org.gnome.Platform branch 42 is end-of-life HOT 2
- System darkmode causes very low contrast in shortcuts tab HOT 1
- Flatpak com.github.babluboy.bookworm not runing on Debian
- Icon that appears in the LXDE panel (the running program instance) is generic
- Ctrl + F search returns, "No matches found". HOT 2
- You are still running org.gnome.Platform on branch 42, which is end of life. HOT 6
- Crashes and freezing when loading large cbz files HOT 1
- webkit2gtk4.0 will be obsoleted HOT 1
- Preferences Shortcut tab can't see content when using Dark mode theme HOT 1
- meson.build:2:0: ERROR: Could not execute Vala compiler "valac" HOT 3
- flatpak Gnome platform runtime version 42 and Platform 21.08 has reached end of life HOT 1
- Restore page position HOT 2
- Bookworm Flatpak not opening in Linux Mint 21.3 "Virginia" Cinnamon Edition
- Unable to load epub file
- Unable to install on Kali linux HOT 1
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 bookworm.