Test AnyLinux AppImage

[mcarans]

An AnyLinux universal AppImage has been created by the AnyLinux dev based off the Arch AUR build (not Flatpak which was not recommended): https://github.com/pkgforge-dev/Anylinu ... ssions/413

The AppImage the dev built is here: https://github.com/pkgforge-dev/oolite- ... 1774584818

Packaging for it is here and looks quite simple: https://github.com/pkgforge-dev/oolite-appimage-demo

Please test. It worked fine for me. Note that since the AUR is 1.92 not 1.92.1 it does not have some of the most recent fixes for centring etc.

[Lone_Wolf]

It would have been nice if you had alerted me to that. You do realise who maintains aur oolite & oolite-git ?

I am looking at updating the package to the last commit of the 1.92.maintenance branch , but hit a snag.

https://github.com/OoliteProject/oolite/pull/561 changed a lot of things in src/oolite/installers/FreeDesktop .

- The oolite.desktop was replaced by space.oolite.Oolite.desktop .

- it has Exec=run_oolite.sh which is in src/oolite/ShellScripts/Linux .
No idea if that's suitable for the archlinux package

- there's also Icon=space.oolite.Oolite
6 icon files are present in the FreeDesktop folder but none of them has that name.
Actually there's no file with that name in the entire sourcecode .

I need to investigate how to deal with that before I can push an update .

[mcarans]

It would have been nice if you had alerted me to that. You do realise who maintains aur oolite & oolite-git ?

I am looking at updating the package to the last commit of the 1.92.maintenance branch , but hit a snag.

https://github.com/OoliteProject/oolite/pull/561 changed a lot of things in src/oolite/installers/FreeDesktop .

- The oolite.desktop was replaced by space.oolite.Oolite.desktop .

- it has Exec=run_oolite.sh which is in src/oolite/ShellScripts/Linux .
No idea if that's suitable for the archlinux package

- there's also Icon=space.oolite.Oolite
6 icon files are present in the FreeDesktop folder but none of them has that name.
Actually there's no file with that name in the entire sourcecode .

I need to investigate how to deal with that before I can push an update .

If you look at the thread, I asked a question about using the flatpak runtime to make appimage and the dev found your AUR and offered to make the appimage. I hadn't expected the offer and within around 20 minutes, they'd already completed it!

run_oolite.sh was also in 1.92 for Linux to allow for differing folder structures in app image, flatpak and distros. The changes in 1.92.1 were bug fixes and to support AppimageHub as requested by Hiran.

[Lone_Wolf]

That clarifies how it happened.

I do remember the script was present in 1.92 but it wasn't started from oolite.desktop so I didn't look at it.

The pngs in that folder are screenshots and don't match the oolite logo used as icon.


For now I'll copy oolite.desktop and oolite-icon.png from master (which still has them) and add them as local files to the PKGBUILD.
That should allow me to release an updated package this weekend.

[mcarans]

That clarifies how it happened.

I do remember the script was present in 1.92 but it wasn't started from oolite.desktop so I didn't look at it.

The pngs in that folder are screenshots and don't match the oolite logo used as icon.


For now I'll copy oolite.desktop and oolite-icon.png from master (which still has them) and add them as local files to the PKGBUILD.
That should allow me to release an updated package this weekend.

It is this script that copies the appropriate file according to the freedesktop standard used by appimage and flatpak: https://github.com/OoliteProject/oolite ... ktop_fn.sh

It sets up the appdata/metainfo xml (unfortunately appimage uses the old name and flatpak the new but contents are the same), It copies oolite, run_oolite.sh and splash-launcher from the oolte.app folder to the app folder/bin along with the Resources folder.

It also copies GNUstep.conf.template into app folder/bin/Resources - that template is used by run_oolite.sh to generate the GNUstep.conf file that sets the locations of the GNUstep folder and GNUstep user defaults directory.

The desktop file was renamed and is in installers/FreeDesktop/space.oolite.Oolite.desktop - that is copied by the script to app folder/share/applications.

The icon is copied from oolite.app/Resources/Textures/oolite-logo1.png to app folder/share/icons/hicolor/256x256/apps/space.oolite.Oolite.png by the script.

The Resources folder in oolite.app is created during the build. Its structure is slightly different to the original Resources folder (maybe due to using Git submodules). So oolite-logo1.png originally comes from Resources/Binary/Textures/oolite-logo1.png (starting from root of project).

[Lone_Wolf]

That suggests the scripts perform these functions : install , first_run & user config , start oolite .

I'll need to replicate the installer part in the PKGBUILD, for first_run & user config I'll need one or more user scripts that will probably be called from a wrapper to start oolite.

PKGBUILDs need to be in control of the package, running an installer script means the PKGBUILD transfers control to that script .

Packages are also strictly forbidden to touch user folders, so first run / user config that isn't done by the executable needs custom scripts .
I might be able to use upstream scripts for that , but typically such scripts need so much changes to work correctly on archlinux it's less work to write them myself.

Guess I'll be busy analyzing scripts tomorrow.

[mcarans]

That suggests the scripts perform these functions : install , first_run & user config , start oolite .

I'll need to replicate the installer part in the PKGBUILD, for first_run & user config I'll need one or more user scripts that will probably be called from a wrapper to start oolite.

PKGBUILDs need to be in control of the package, running an installer script means the PKGBUILD transfers control to that script .

Packages are also strictly forbidden to touch user folders, so first run / user config that isn't done by the executable needs custom scripts .
I might be able to use upstream scripts for that , but typically such scripts need so much changes to work correctly on archlinux it's less work to write them myself.

Guess I'll be busy analyzing scripts tomorrow.

Since I understand AUR follows the freedesktop conventions, you should be able to do in the package() part of PKGBUILD:

Code: Select all

source ShellScripts/Linux/install_freedesktop_fn.sh
install_freedesktop "$pkgdir/usr" metainfo

The thing I'm puzzled about in your package is how the Resources folder gets found as I thought it has to be in the same folder as the oolite binary. I can't see anything in the code that gets oolite to look in /usr/share/oolite/Resources or ../share/oolite/Resources. I guess it's a GNUstep thing, but not sure.

EDIT: I checked the GNUstep filesystem layouts and I see nothing in there that would use /usr/share/oolite either so I'm stumped. It didn't work for me when I tried using that folder for Resources within an appimage. (I uncompressed an appimage, moved the Resources folder to usr/share/oolite and then made the appimage.)

[Lone_Wolf]

The thing I'm puzzled about in your package is how the Resources folder gets found as I thought it has to be in the same folder as the oolite binary. I can't see anything in the code that gets oolite to look in /usr/share/oolite/Resources or ../share/oolite/Resources. I guess it's a GNUstep thing, but not sure.

the last line of oolite wrapper script sets an envvar and executes /usr/share/oolite/oolite with that envvar .

part of latest.log

Code: Select all

22:25:26.560 [searchPaths.dumpAll]: Resource paths: 
    /usr/share/oolite/Resources
    ~/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns
    ~/.Oolite/AddOns

Maybe the oolite executable determines from where it is started and appends Resources to it ?

The install_freedesktop_fn.sh appears to copy lots of stuff to certain destinations
- oolite executable , run_oolite.sh and splash-launcher
- Resources folder
- add GNUstep.conf.template to Resources folder
- space.oolite.Oolite.metainfo.xml.template
- space.oolite.Oolite.desktop
- space.oolite.Oolite.png
It also changes metainfo version & date

All those actions should be done in the pacakge() function the PKGBUILD.
As I said :
PKGBUILD should be in control and not call on some script.

This has the added benefit that looking at the PKGBUILD is enough to understand what changes it makes to system folders.
No need for users to to download sourcecode to see what the content is of a script.

[mcarans]

The thing I'm puzzled about in your package is how the Resources folder gets found as I thought it has to be in the same folder as the oolite binary. I can't see anything in the code that gets oolite to look in /usr/share/oolite/Resources or ../share/oolite/Resources. I guess it's a GNUstep thing, but not sure.

the last line of oolite wrapper script sets an envvar and executes /usr/share/oolite/oolite with that envvar .

part of latest.log

Code: Select all

22:25:26.560 [searchPaths.dumpAll]: Resource paths: 
    /usr/share/oolite/Resources
    ~/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns
    ~/.Oolite/AddOns

Maybe the oolite executable determines from where it is started and appends Resources to it ?

The install_freedesktop_fn.sh appears to copy lots of stuff to certain destinations
- oolite executable , run_oolite.sh and splash-launcher
- Resources folder
- add GNUstep.conf.template to Resources folder
- space.oolite.Oolite.metainfo.xml.template
- space.oolite.Oolite.desktop
- space.oolite.Oolite.png
It also changes metainfo version & date

All those actions should be done in the pacakge() function the PKGBUILD.
As I said :
PKGBUILD should be in control and not call on some script.

This has the added benefit that looking at the PKGBUILD is enough to understand what changes it makes to system folders.
No need for users to to download sourcecode to see what the content is of a script.

You are right. I had asked AI and it explained it to me about the separate launcher coped to /usr/bin which launches the oolite binary in/usr/share/oolite. This is a bit of a hack since executables are not really supposed to go in /usr/share. I think we should fix the code to try looking in ../share/oolite for stuff (similar to what I had to do for the espeak-ng package on MSYS2 as well).

Setting this should not be necessary: ESPEAK_DATA_PATH=/usr/share/espeak-ng-data/. The Oolite build copies the espeak-ng-data folder from the installed package during build into Resources and modifies one voice (another_commanders change of the female voice).

I created the freedesktop script so there would not be duplication between building an appimage vs building flatpak but you propose duplicating the contents of that file into PKGBUILD which means that you will need to ensure it is kept in sync with any changes in logic in the upstream file.

FlatHub maintainers wanted the opposite of what you suggest for AUR - that everything be done upstream in the source package not by adding steps in the FlatHub build. Is what you have said AUR standard practice?

EDIT: Thinking about the process, building the AppImage from AUR would make producing test packages for people to try difficult and restrict AppImage creation to only Arch developers, but it's good to know that in principle AnyLinux AppImage works with Oolite. So no need for you to rush the AUR release on account of AnyLinux as I will need to add building those directly to the Oolite source build.

[Lone_Wolf]

Setting this should not be necessary: ESPEAK_DATA_PATH=/usr/share/espeak-ng-data/. The Oolite build copies the espeak-ng-data folder from the installed package during build into Resources and modifies one voice (another_commanders change of the female voice).

It was necessary to set that var to get any speech, have to test if it's still needed.

I created the freedesktop script so there would not be duplication between building an appimage vs building flatpak but you propose duplicating the contents of that file into PKGBUILD which means that you will need to ensure it is kept in sync with any changes in logic in the upstream file.

That's part of the job description of a downstream maintainer

FlatHub maintainers wanted the opposite of what you suggest for AUR - that everything be done upstream in the source package not by adding steps in the FlatHub build. Is what you have said AUR standard practice?

You may find Fosdem 2018 How to make package managers cry and Fosdem 2026 How to make package managers scream intererting .


I'm not sure if it's mentioned in Arch_package_guidelines .

However if a PKGBUILD which sources external scripts and runs a function from them is submitted to archlinux forum or aur-general mailing list for review is very likely to get qualifications like :
low quality, sloppy coding, lazy maintainer, not ready to submit to aur, in case you're not willing to create a decent package don't bother starting one.

sidenote :
Since I need time to spend on syncing master & 1.92-maintenance , I'll focus on the quick & dirty method of updating the aur oolite package to build 1.92-maintenance and add implementing as much as possible of new scripts in upstream code to todo-list.