AppImage #907
AppImage #907
Conversation
|
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:
|
|
Err, I don't have "fetch by chemical name"... |
|
Does anyone know what means? |
|
OK, well here's what it (the fetch option) looks like on my PC:
|
|
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
|
|
@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: |
|
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. Can we continue this on the discussion forum? |
I hope the video shows everything clearly step-by-step that allows you to make one.
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...
What do I want to build against then?
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.)
You should be able to see this in the
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. |
I see on your example page that it indicates a continuous pre-release. I guess my question is whether a new
https://github.com/openbabel/openbabel/tree/openbabel-2-4-x
Yes, at the moment, Open Babel loads data files and plugin libraries using either absolute paths or environment variables.
|
Yes, a new git push replaces the existing AppImage. I am using https://github.com/probonopd/uploadtool to do this.
OK, in this case one would have to replace the default |
|
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. |
|
Can we learn from how it is done for macOS here? |
|
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. |
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:
appimaged--appimage-extractparameterHere 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_TOKENin 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.