Open munix9 opened 5 years ago
Sounds like a case for a custom AppRun script?
Sounds like a case for a custom AppRun script?
I'm sorry, i don't get. Could you explain a little bit?
With #335 merged, this:
create a portable home folder to use as $HOME
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-home
create a portable config folder to use as $XDG_CONFIG_HOME
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-config
and this:
"Error Saving Bookmarks" "Read-only file system" on exit
$ mkdir -m 700 ~/celestia-app/celestia-qt-latest-x86_64.AppImage.home/.config
is not required any more (crossing my fingers :) )
I'm sorry, i don't get. Could you explain a little bit?
From what you wrote it seems like the user has to export certain environment variables in order to make this work. What I wanted to point to is AppRun
, a file inside the AppImage which you can use to write your own script, that would export the needed environment variables.
Let me know if you are stuck and need concrete help.
With #335 merged, this:
create a portable home folder to use as $HOME $ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-home create a portable config folder to use as $XDG_CONFIG_HOME $ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-config
and this:
"Error Saving Bookmarks" "Read-only file system" on exit $ mkdir -m 700 ~/celestia-app/celestia-qt-latest-x86_64.AppImage.home/.config
is not required any more (crossing my fingers :) )
Please note:
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-home
$ ./celestia-qt-latest-x86_64.AppImage --appimage-portable-config
have nothing to do with problems or errors, on the contrary, they offer the possibility to store configurations and the like not under $HOME/, $HOME/.config, $HOME/.local, but under the above mentioned portable directories.
Sorry, then I was misunderstanding. In fact it's really as simple as those 3 steps:
wget -c https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-latest-x86_64.AppImage # Download
chmod +x celestia-qt-latest-x86_64.AppImage # Make executable
./celestia-qt-latest-x86_64.AppImage # Run
Here it is running on Xubuntu 18.04:
Awesome! :+1:
I'm sorry, i don't get. Could you explain a little bit?
From what you wrote it seems like the user has to export certain environment variables in order to make this work. What I wanted to point to is
AppRun
, a file inside the AppImage which you can use to write your own script, that would export the needed environment variables.Let me know if you are stuck and need concrete help.
It would certainly be an advantage to clean up https://build.opensuse.org/project/show/OBS:AppImage, install new versions and fix the existing unresolvable/failed/broken builds. But there are others in charge, I'll probably make a bug entry. I've also noticed that AppImageUpdate doesn't work correctly with the AppImages generated by OBS - but I need to take a closer look at that.
The thing with libmurrine.so is annoying, yes, but we should wait for further tests of the users on as many platforms as possible.
have nothing to do with problems or errors, on the contrary, they offer the possibility to store configurations and the like not under $HOME/, $HOME/.config, $HOME/.local, but under the above mentioned portable directories.
Seems that you are correct, because as I see if you don't explicitly create those dirs appimage use default $HOME etc.
But frankly speaking --appimage-portable-config
required only for those who has nondefault $XDG_CONFIG_HOME
. And appimage doesn't have means to redefine $XDG_DATA_HOME
.
I tried with two different updater tools and neither was able to update it correctly:
https://github.com/AppImage/AppImageUpdate
https://github.com/antony-jr/AppImageUpdater
This message is actually very helpful @antony-jr. We can see:
me@host:~$ strings Downloads/celestia-qt-0-Build160.1.glibc2.14-x86_64.AppImage | strings | grep zsync
zsync|https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-latest-x86_64.AppImage.zsync
(...)
me@host:~$ wget https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-latest-x86_64.AppImage.zsync
--2019-08-04 20:57:11-- https://download.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-latest-x86_64.AppImage.zsync
(...)
HTTP request sent, awaiting response... 302 Found
Location: http://downloadcontent.opensuse.org/repositories/home:/munix9:/unstable/AppImage/celestia-qt-0-Build160.1.glibc2.14-x86_64.AppImage.zsync [following]
So it seems like there is a bug in https://download.opensuse.org that makes it redirect to http rather than to https. This used to work; so I suspect it to be a bug that was recently introduced.
cc @AdrianSchroeter
appimage doesn't have means to redefine $XDG_DATA_HOME
Do you think we should add it?
I tried with two different updater tools and neither was able to update it correctly:
https://github.com/AppImage/AppImageUpdate
https://github.com/CelestiaProject/Celestia/issues/333#issuecomment-518027817
yep, I was thinking something like that, thanks for testing.
For celestia AppImageUpdate would be very advantageous, so you don't have to download the whole package with every build.
For celestia AppImageUpdate would be very advantageous, so you don't have to download the whole package with every build.
Indeed! :+1:
appimage doesn't have means to redefine $XDG_DATA_HOME
Do you think we should add it?
This sounds logical to me.
Would you be interested in having an updater inside the application? There is a Qt plugin that can do it. https://github.com/TheFutureShell/updatedeployqt cc @antony-jr
Would you be interested in having an updater inside the application? There is a Qt plugin that can do it. https://github.com/TheFutureShell/updatedeployqt cc @antony-jr
That sounds interesting. I'll take a closer look.
@munix9 let me know if you want to integrate the updater into your application. You can also use https://antony-jr.github.io/AppImageUpdaterBridge which can be used as a library or as a Qt plugin to do the self update. Its entirely written in Qt and respects the event loop.
PS: updatedeployqt is still in alpha and it gets a open heart surgery every week so I'm not very confident to recommend it to you.
@munix9 If you want to see how the update works, See how qtox uses it -> https://github.com/qTox/qTox-nightly-releases/releases
After downloading it, add some garbage data to trigger an update,
$ echo "changes" >> qTox-*-x86_64.AppImage
$ ./qTox-*-x86_64.AppImage
go to settings -> about -> update available (button will appear after some time)
FYI: I used https://github.com/antony-jr/updatedeployqt to test the update option (the "1" tag, the "continuous" tag doesn't seem to work at the moment). I think it's a quick and easy way to try out an integrated update functionality - the code doesn't need to be changed - except for assigning a QObject name for the help menu. AppImageUpdaterBridge seems to be an interesting alternative - let's see what the future holds.
https://github.com/munix9/Celestia/releases/tag/continuous https://github.com/munix9/Celestia/blob/appimage_build/dist/appimage/fix-appimage_dir.patch#L43
except for assigning a QObject name for the help menu.
You can also try matching the substring of all QMenu objects or QAction objects in the program.
EDIT: I did not add any documentation since I really don't have the time(buf I'm very excited) and the tool is still in alpha so major changes are yet to come.
@munix9 The updater works great on my side. :+1:
except for assigning a QObject name for the help menu.
You can also try matching the substring of all QMenu objects or QAction objects in the program.
EDIT: I did not add any documentation since I really don't have the time(buf I'm very excited) and the tool is still in alpha so major changes are yet to come.
@munix9 The updater works great on my side. +1
A thing that might be better solved: If an update is available, then the new file gets the name e.g.
celestia-qt-continuous-x86_64-revised-on-2019-08-29T10-57-48.AppImage
This makes the existing directories
celestia-qt-continuous-x86_64.AppImage.config
celestia-qt-continuous-x86_64.AppImage.home
obsolete because they are not automatically renamed.
Is there a solution for this?
A thing that might be better solved: If an update is available, then the new file gets the name e.g.
celestia-qt-continuous-x86_64-revised-on-2019-08-29T10-57-48.AppImage
@munix9 Actually, the updater renames it only if a file with the target filename exists, in the official updater, the old file is moved with the extension .zs_old
but I decided to not touch the old version and let the users handle it. We can however add a option to delete the old file when this conflict occurs, or we can rename it just like how the official updater does.
Also if we keep moving old version with the extension .zs_old
, other such version will be lost forever. In case the AppImage uses the same name for every release like in your case.
First of all, only ONE of the following should be used:
celestia-qt-continuous-x86_64.AppImage.config
celestia-qt-continuous-x86_64.AppImage.home
Normally, portable applications are supposed to keep their configuration per-version, so that a user could run multiple versions of the same application alongside without them interfering with each other. If you want different versions of the application to share the same set of configuration, you could, as part of a custom AppRun
, do something like (untested pseudo-code):
VERSIONLESSHOME=$(dirname "$APPIMAGE")/celestia.home
if [ -d "$VERSIONLESSHOME" ] ; then
export HOME=$VERSIONLESSHOME
fi
Then it will use celestia.home
if it is there, independent of the filename of the AppImage.
Does this make sense?
Yes, AppImage.home
should be sufficient.
I had already considered and tested an adaptation in the AppRun.
Maybe with a fallback, if a version-AppImage.home
does not exist for the current version, then use the general AppImage.home
if available - similar to what you suggest.
This might make sense.
Let's see if there's any revealing feedback from the users.
Hello, can we put the addons? and if so, in which directory? Thank you
@Amich-26 Celestia 1.7 reads ~/.celestia.cfg
if it exists.
In the file you can add ExtrasDirectories
with directories with addons:
Configuration
{
ExtrasDirectories [ "extras-standard" "extras" "~/celestia"]
}
Please note that all directories must be listed, not only an additional one.
Actually @munix9 adds a patch for celestia.cfg
, so you can use ~/.celestia
to put addons.
It is also possible to extract the embedded data in the AppImage:
./celestia-1.7.0-git-x86_64.AppImage --celestia-extract-data
Addons can then be placed in the folder created and then started using CELESTIA_DATA_DIR=<dir> ./celestia-1.7.0-git-x86_64.AppImage
.
See also ./celestia-1.7.0-git-x86_64.AppImage -h
Celestia 1.7.0~git - Real-time visual space simulation
Usage: ./celestia-1.7.0-git-x86_64.AppImage [OPTION]...
CELESTIA_DATA_DIR=<dir> ./celestia-1.7.0-git-x86_64.AppImage [OPTION]...
Celestia options:
--conf <file>
Alternate configuration file.
--dir <dir>
Alternate installation directory.
The same can also be achieved with
CELESTIA_DATA_DIR=<dir> ./celestia-1.7.0-git-x86_64.AppImage
--extrasdir <dir>
Additional 'extras' directory.
--fullscreen
Start full-screen (not implemented yet).
-l, --log <file>
Copy console output into a file.
-s, --nosplash
Disable splash screen (not implemented yet).
-u, --url <url>
Start with the given URL (not implemented yet).
--help
Show celestia help (not implemented yet).
AppImage options:
--celestia-fisheye
Start celestia with fisheye projection (celestia-fisheye.cfg)
--celestia-create-general-home
Create a general home directory depending on the main version
/tmp/celestia-1.7.home
--celestia-extract-data
Extract the embedded data in the directory
/tmp/celestia-1.7.0-git-x86_64.AppImage.data
-h, --celestia-help
Show this help and exit.
thank you ! It works.
FYI: AppImages v1.6 and v1.7 are now based on openSUSE Leap 15.3, as version 15.2 is EOL as of 01/2022.
I get a problem with 1.7.0 AppImage on Linux Mint 20.3:
/tmp/.mount_celestymsaTK/usr/bin/celestia: /lib/x86_64-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.29 not found (required by /tmp/.mount_celestymsaTK/usr/bin/celestia)
while the package version from the repository works there.
"Solved" the problem by adding the contents of the package libstdc++6 from there: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test to AppDir.
I get a problem with 1.7.0 AppImage on Linux Mint 20.3:
/tmp/.mount_celestymsaTK/usr/bin/celestia: /lib/x86_64-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.29 not found (required by /tmp/.mount_celestymsaTK/usr/bin/celestia)
while the package version from the repository works there."Solved" the problem by adding the contents of the package libstdc++6 from there: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test to AppDir.
Last release was rebuilt with gcc 10, should make less problems (GLIBCXX_3.4.26). The distribution to the mirrors can still take some time.
It's working fine now, thanks.
It's working fine now, thanks.
thanks for the feedback!
AppImages are back on OBS.
eg.
1.7.x
create a portable, main version-dependent $HOME directory in the same folder as the AppImage file
start Celestia / get help (filename may change after updates)
1.6.x
create a portable, main version-dependent $HOME directory in the same folder as the AppImage file
start Celestia / get help (filename may change after updates)
Optional: Updates via AppImageUpdate
optionally create a portable $HOME directory in the same folder as the AppImage file
Optional: Import gpg public key (gpg2 must be installed)
global (without a portable $HOME for AppImageUpdate)
for AppImageUpdate only (portable $HOME, see above)
old stuff
**Build system:** - openSUSE Leap 42.3 x86_64 **Test systems:** - [x] Ubuntu 18.04.2 amd64 (VM) - [x] Xubuntu 18.04 - [x] openSUSE Tumbleweed **Version: celestia-qt, git master (with additional hacks/patches and spice enabled)** The AppImage test environment has now moved from OBS to github/travis-ci https://github.com/munix9/Celestia (branch appimage_build) Updates should now be possible via https://github.com/AppImage/AppImageUpdate ## Howto create a working directory (is arbitrary, can be moved or renamed later) ``` $ mkdir ~/celestia-app $ cd ~/celestia-app ``` download the AppImage file from https://github.com/munix9/Celestia/releases (Continuous build) ``` $ wget https://github.com/munix9/Celestia/releases/download/continuous/celestia-qt-continuous-x86_64.AppImage ``` and make it executable ``` $ chmod 755 celestia-qt-continuous-x86_64.AppImage ``` create a portable home folder to use as $HOME ``` $ ./celestia-qt-continuous-x86_64.AppImage --appimage-portable-home ``` Hint: There is now an alternative for a portable $HOME directory. If a writable directory named `celestia-qt.home` exists in the same folder as the AppImage, this directory is defined as portable $HOME. This should make it easier to handle the different AppImage names after updates. --- venture a first start ``` $ ./celestia-qt-continuous-x86_64.AppImage ``` ## Troubleshooting, general"Error Saving Bookmarks" "Read-only file system" on exit - solved (#335)
``` $ mkdir -m 700 ~/celestia-app/celestia-qt-continuous-x86_64.AppImage.home/.config ```(celestia-qt:...): Gtk-WARNING **: ...: Unable to locate theme engine in module_path: "murrine", - solved, should not occur again
first install gtk2-engines-murrine ``` $ sudo apt-get install gtk2-engines-murrine ``` solution by prepending the GTK_PATH64 env var when the AppImage is started ``` $ GTK_PATH64=$GTK_PATH64:/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/ ./celestia-qt-continuous-x86_64.AppImage ``` or by creating a symbolic link ``` $ mkdir -p ~/celestia-app/celestia-qt-continuous-x86_64.AppImage.home/.gtk-2.0/engines $ ln -s /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/libmurrine.so ~/celestia-app/celestia-qt-continuous-x86_64.AppImage.home/.gtk-2.0/engines/ ```