avogadro
avogadro copied to clipboard
cryos
AppImage
This PR, when merged, will compile this application on Travis CI upon each git push, and upload an AppImage to your GitHub Releases page.
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
- Can be listed in the AppImageHub central directory of available AppImages
- Can double as a self-extracting compressed archive with the
--appimage-extractparameter
Here is an overview of projects that are already distributing upstream-provided, official AppImages.
PLEASE NOTE: For this to work, you need to enable Travis CI for your repository as described here prior to merging this, if you haven't already done so. Also, You need to set up GITHUB_TOKEN in Travis CI for this to work; please see https://github.com/probonopd/uploadtool.
If you would like to see only one entry for the Pull Request in your project's history, then please enable this GitHub functionality on your repo. It allows you to squash (combine) the commits when merging.
If you have questions, AppImage developers are on #AppImage on irc.freenode.net.
Test builds of the Avogadro AppImage are available for download at https://github.com/probonopd/avogadro/releases. Let me know if there are any remaining issues.
It's a good thing that I listened to that voice in my head that said to test this AppImage beyond just seeing if it starts... On KDE Neon git unstable (which is remarkably otherwise stable despite its name :P) running this, then going File->Import->Fetch by chemical name... causes it to crash. Here's the output at the command-line:
OpenGL capabilities found:
Double Buffering.
Direct Rendering.
Antialiasing.
==============================
*** Open Babel Warning in Init
Cannot open element.txt defaulting to compiled data.
QStackedLayout::setCurrentWidget: Widget 0x2606b90 not contained in stack
libpng warning: Ignoring attempt to set cHRM RGB triangle with zero area
Cannot mix incompatible Qt library (version 0x40807) with this library (version 0x40806)
[1] 30326 abort (core dumped) ./Avogadro*.AppImage
Oh one more thing. I think there's something wrong with the Open Babel backend, as trying to open a CML files gives the error:
Does anyone know what
*** Open Babel Warning in Init
Cannot open element.txt defaulting to compiled data.
means?
Most likely we need some developer of this application who knows how it works to have a look and debu things from here.
I don't have that... running on openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20180530-Media.iso:
@probonopd I saw your video (had a few more hours left in the day than I realized). I'm wondering whether the build instructions might be outdated. Maybe the latest Open Babel (2.4.1) might be preferable, after all if you're a dev of this package trying to check if the latest commit works by attempting to build it you'd probably have the latest stable release of Open Babel (2.4.1), at least, so consequently a dependency on newer Open Babel may not have been detected yet (just theorizing, I could be completely wrong). Distro packagers wouldn't have noticed this since they stick to stable releases, instead of building from the latest commit like this Travis CI instance is. Unfortunately that'd mean more source compiling...
EDIT: Maintainers of this project, do you's agree?
This pull request has been mentioned on Avogadro Discussion. There might be relevant details there:
https://discuss.avogadro.cc/t/appimage-builds/2739/1
Somehow I didn't see this PR. Yes, having an AppImage would be great, particular for a final 1.3 release, but I'm not sure I want one uploaded to the release page with every commit...
No, you don't want to build against Open Babel master. The error indicates that the Open Babel build is installed in a funny way. I'd have to see how the build occurs. Do AppImages use relative paths?
Can we continue this on the discussion forum?
Yes, having an AppImage would be great, particular for a final 1.3 release
I hope the video shows everything clearly step-by-step that allows you to make one.
I'm not sure I want one uploaded to the release page with every commit...
Personally I find this very convenient for testing, but in case you don't want to upload those, just don't. You can use the GitHub Releases Provider instead, which will only upload tagged releases. But why not have one for each git push...
No, you don't want to build against Open Babel master.
What do I want to build against then?
The error indicates that the Open Babel build is installed in a funny way. I'd have to see how the build occurs. Do AppImages use relative paths?
AppImage does not really install anything into the base system, but rather just mounts a filesystem image at a temporary path and executes whatever is inside it. The payload should use relative rather than absolute paths to make this work. (It may be necessary to make some changes in the payload's source code to make this happen.)
I'd have to see how the build occurs.
You should be able to see this in the .travis.yml file of the PR.
Can we continue this on the discussion forum?
Sure, but please ping me in this thread so that I am aware whenever new posts happen in the forum. I am not checking forums proactively, but I do get notified by GitHub if someone responds here.
Personally I find this very convenient for testing, but in case you don't want to upload those, just don't. You can use the GitHub Releases Provider instead, which will only upload tagged releases. But why not have one for each git push...
I see on your example page that it indicates a continuous pre-release. I guess my question is whether a new git push replaces the existing AppImage? I mean, is there one pre-release, or does it keep a list of builds after each push?
What do I want to build against then?
https://github.com/openbabel/openbabel/tree/openbabel-2-4-x
The payload should use relative rather than absolute paths to make this work. (It may be necessary to make some changes in the payload's source code to make this happen.)
Yes, at the moment, Open Babel loads data files and plugin libraries using either absolute paths or environment variables.
-
BABEL_DATADIRto point to data files like/usr/local/share/openbabel/2.4.1/element.txt -
BABEL_LIBDIRto point to plugins like/usr/local/lib/openbabel/2.4.1/*.so
I see on your example page that it indicates a continuous pre-release. I guess my question is whether a new git push replaces the existing AppImage? I mean, is there one pre-release, or does it keep a list of builds after each push?
Yes, a new git push replaces the existing AppImage. I am using https://github.com/probonopd/uploadtool to do this.
Yes, at the moment, Open Babel loads data files and plugin libraries using either absolute paths or environment variables.
OK, in this case one would have to replace the default AppRun symlink by a custom script with the same name that would export these environment variables, similar to what is done at
https://github.com/ImageMagick/ImageMagick/blob/6b6bff054d569a77973f2140c0e86366e6168a6c/.travis.yml#L37
It may have broken, but BABEL_DATADIR and BABEL_LIBDIR are attempted to be set in avogadro/src/main.cpp. I remember Open Babel kept changing things, and that would occasionally break. Maybe we just need to fix that as it is used on Windows, macOS, and Linux (at least in theory), and should remove the need for a wrapper script.
From looking at your report I suspect that it is failing to account for the version in the path. I really think versioned plugins, data etc make sense when slotting versions in a distro or something, but for packaging they have proven to be an irritating source of issues with no benefit across a number of projects. I was one of the people pushing to do it better, but ideally turning off versioned plugins when you only package one version.
The relevant C++ code is here, it is wrapped in AVO_APP_BUNDLE, and could likely be adapted to help when making a relocatable package on Linux too. I suspect that injecting AVO_APP_BUNDLE when making this might help, but if the Open Babel directory is versioned they do not have any version info in the logic outlined.