Portable package formats -Request

[alextrical]

I believe it would be useful to have a tool like this able to be run as an Appimage (or Flatpack) to allow easy cross Linux platform distribution for the end user, and to support Atomic/Immutable OS's such as Fedora Silverblue

[Spagett1]

This is definately something i am interested in doing

[alextrical]

I can take a look into how to package up files on Linux, and see if it's possible to get a fork able to compile the Appimage for example (I'm hoping there is some form of GitHub automation for that)

[alextrical]

I'm going to have a look through these guides to see what is possible to get GitHub actions to build a working image. If it can be made to work, I'm tempted to utilise this project for uploading to the Polyformer Project too https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages/cc2441518975caca23e9ce2dba6f08a22c678d1e

https://appimage-builder.readthedocs.io/en/latest/hosted-services/github-actions.html

[Spagett1]

Gday, I was doing some testing with appimages the other week.

I managed to create one however the file selector for flashing files manually is broken as it can't find the proper gtk libs inside the appimage.

The other issue was pkexec (how we gain root permissions for flashing on Linux), that had a similar issue as since it was not inside the appimage it could not be used.

I'm not sure if it is best to include these in the appimage manually or what.

The tool I used to create this though was a cargo extension called cargo-appimage or something similar.

[Spagett1]

A small thing I did was to work around blisp and dfu-util not being in the PATH of the appimage I added

.env(PATH, "/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/path/to/folder/in/appimage/with/blisp/and/dfu-util") 

to the flash commands.

I'm not quite certain that's best practices and a compile option for when compiling for appimages may be better as I'm not certain hardcoding the path is the best. There may also be a rust std::env::path variable or something similar that could also be used in that argument and the path to the flashing tools could be appended to that rather than hardcoding it all.

[alextrical]

From what I can tell the Appimage format ideally wants all dependancies to be included in the file, so that it becomes a stand alone file, and will run regardless of what is installed on the end users system

This does result in a larger file, but gives a functional application on any platform it's run on

A good example looks to be here https://github.com/AppImageCrafters/build-appimage

[Spagett1]

Yeah that's my understanding, I'm just not entirely sure which gtk luv files I'll need to grab and if pkexec will need anything or if it will even work in an appimage

[alextrical]

Unfortunately I'm not sure im regards to exact dependencies that will be needed or be safe to exclude, but testing will surface any issues we come across, and anything that comes up is likely been an issue that's also been resolved for others

[Spagett1]

Yeah, unfortunately I'm quite busy at the moment with things outside of development so it will be a while before anything much happens. If anyone wouldn't mind helping out id appreciate it.

[qwertychouskie]

I ran the appimage, but get *** stack smashing detected ***: terminated in the terminal immediately.

[Spagett1]

Interesting, ive tried looking up that issue but it seems to be a buffer overflow message for C++ so I'm really not sure how the problem is arising.

[Spagett1]

I've now got the appimage working reliably now, I wouldn't mind adding flatpak support in the future but it's not a priority.