Create Portable AppImage (or selfextracting script)

[fredx181]

*** Create Portable AppImage (or selfextracting script) ***

Update: 2020-04-21, v2.1 download links below replaced, more info:
http://murga-linux.com/puppy/viewtopic. ... 89#1056089
Update: 2019-04-02, v2.0 download links below replaced, more info and tips:
http://murga-linux.com/puppy/viewtopic. ... 16#1011816

Options:
- 'PortableAppsLinux Mode' or 'Chroot mode' choice
The 'Chroot Mode' gives a better chance that the app will run (specially with complex apps)
But for simple apps, I'd recommend 'PortableAppsLinux Mode' (runs faster)
(see more info below)
- Create appimage from selected directory "AppDir", or
- Create appimage from selected .sfs or .squashfs (Chroot Mode only)
- Create selfextracting script instead of appimage (using makeself https://makeself.io/)

Contents of Info (click Info button at the GUI):
--------------------------------------------------------------------------
*** About preparing a directory for creating an Appimage, or self-extracting script ***
Check the box: 'Create self-extracting script instead of appimage' for the latter
Advantage of an AppImage is that it is mounted in /tmp, this way it does not take any space
In contrary to self-extracting script, which extracts the files in /tmp
This program will create a script AppRun (+ other requirements) in the chosen directory (<appdir-root>)
- The directory should contain the executable, e.g abiword, and it must be in one of the directories in PATH
(e.g. <appdir-root>/usr/bin, <appdir-root>/usr/sbin)
- Also it should contain all required dependencies, e.g. libs, place them in <appdir-root>/usr/lib or <appdir-root>/usr/lib/i386-linux-gnu
Place an icon e.g. <programname>.png in <appdir-root>/ or in <appdir-root>/usr/share/pixmaps/ EDIT This is not required
For creating self-extracting script this is not needed
Info only for DebianDog or XenialDog (has included apt2sfs):
Besides creating the directory manually, you can also use a directory created by apt2sfs,
just run apt2sfs, (cancel creating .squashfs) and choose 'No' when prompted for removing the directory
Or: unsquash an existing .sfs or .squashfs or .pet and use the extracted directory as base <appdir-root>
Or: Select a .sfs or .squashfs instead of an AppDir

*** Chroot Mode: About how it works ***
The way of portablizing is different from the method that is used by portablelinuxapps
(http://portablelinuxapps.org/)
Running the appimage will create a mountpoint (in /mnt/unionfs-xxxxxx) and by using unionfs-fuse the AppDir will be merged with the (also mounted) filesystem
Then the command will be executed inside a chroot environment (jail)
The advantage is that there is more chance that the application will run properly, but the application start time is a little slower than when using the "Portablelinuxapps Mode"
Part of this program has been taken from "AppImageAssistant" by Simon Peter (probono), known from (earlier) http://portablelinuxapps.org and https://github.com/AppImage/AppImageKit
--------------------------------------------------------------------------

Download: Updated: 2020-04-21 to v2.1
32-bit, extract and run create-portable32 (appimage)
https://dl.dropboxusercontent.com/s/npi ... ar.gz?dl=1 (size: 261K)
64-bit, extract and run create-portable64 (appimage)
https://dl.dropboxusercontent.com/s/6go ... ar.gz?dl=1 (size: 248K)

Two examples (appdir and sfs 32-bit) for to try out attached (with screenshots accordingly)
These are from Mike Walsh's ScreenControl-v1.3-i686.pet (ScreenControl v1.3 - SCT-based 32-bit) from here:
http://murga-linux.com/puppy/viewtopic.php?t=114277
The .sfs is created from the extracted .pet, and only added yad in usr/bin/
The appdir is a bit more modified (changed absolute paths to just <command> in scripts, absolute paths won't work for setting up as portable)

The resulting appimage will be: ScreenControl.sh-portable

Fred

[fredx181]

2019-04-02 updated to v2.0, did a lot more testing, fixed bugs and made improvements.
Changes and fixes:
- Fixed a bad bug for the "Chroot mode" (was using very high CPU), now an Appimage created with Chroot mode is running more quiet and much faster)
- Improvements for Portablelinuxapps mode and Chroot mode.
E.g. added more environment variables, like e.g. PYTHONPATH, PERLLIB, QT_PLUGIN_PATH etc..
Download links at first post updated.

Info and tips:

First note that: (disclaimer) this program can be used just as a "helping hand" for creating portable appimages, no guarantees.
EDIT: Also like to add to the above, this is in no way comparable with the way appimages are created when using the (much more advanced) AppimageKit:
https://github.com/AppImage/AppImageKit

In case "Portablelinuxapps mode" is used:
Some cases e.g. if the program to be executed inside the appimage is a script, manual editing may be required if:
- the script calls another script (or executable) by using absolute path.
Solution can be to change absolute to relative, e.g. change /usr/local/bin to: ./usr/local/bin inside the script.
- the script points to an icon, change absolute to relative, similar as above.

In case "Chroot mode" is used there's no need to change things like above.

Testing the Appimage: What is a good test?
For example, you made a vlc appimage, test if it works on a system without vlc installed.
(otherwise it's not a good test and may fail to work on system without vlc installed)

(maybe add some more info later)

Fred

[Mike Walsh]

Afternoon, Fred.

You never cease to amaze me, mate. This is a very, very neat idea, indeed.....especially for smaller utilities.

I can already think of a few I'm going to try this on; my Q.I.V slideshow creator being one for starters!

I've tried out the example for my SCT-based 'ScreenControl' .pet. It works beautifully. I'll be adding this to the thread, I think. Nice one!

One question (if I may?) Is there any practical limit to the size of AppImage you can create? I like AppImages, as you may have guessed; they're a very neat method for using apps (especially where there's not much in the way of dependencies), and make for real 'ease-of-use'...

I've long since discovered that for any AppImages you download, you can chop the .AppImage bit off the end; in fact, you can rename them to anything you like, really. They'll still run....

Cheers.


Mike.

[fredx181]

Thanks Mike !

Good to see that it's appreciated by at least one

Is there any practical limit to the size of AppImage you can create? I like AppImages

Not sure, but I don't think there's a size limit and the appimage will be mounted (in /tmp), so doesn't take any space (in contrary to self-extracting script that will be extracted in /tmp).

I had a go at your qiv-slideshow here (just extracted your .pet and used as <appdir-root>) and worked well for me to create working appimage, except the window icon in the GUI, so I changed in the qiv-gui.sh script the path to the icon to:

Code: Select all

--window-icon=$LAUNCHDIR/usr/local/lib/X11/pixmaps/qiv.png

And the icon showed. (otherwise it would only show if the icon exists by absolute path)
In this case it's "only missing" the window icon, but there could be scripts that depend on more icons (e.g yad or gtkdialog based), so when using the "PortableappLinux Mode", the $LAUNCHDIR variable (= relative path) should go before the icon path (as above).
For executing binaries (or scripts) that's not needed if they are in PATH environment in <appdir-root>, e.g. usr/bin or usr/local/bin, for example qiv-gui-info.sh:
So this in the script works OK:

Code: Select all

--button="Information":qiv-gui-info.sh

But wouldn't be OK if it was:

Code: Select all

--button="Information":/usr/local/bin/qiv-gui-info.sh

Then it looks in the "real" system for (absolute path of) qiv-gui-info.sh

For more complex apps, use the "Chroot Mode", absolute paths are supported then, no need to change to relative (but as I said,"Chroot Mode" is a bit slower starting the app) .

Much more can be said about all this, if have any more questions (or suggestions, bug report maybe), just say.

Fred

[watchdog]

Your program fails to use a full main puppy sfs as chroot jail. I have not gone to delete unneeded stuff in the jail. I have a container on the external usb hd at /cnt where is the extracted main precise sfs with /dev /proc /sys dirs and where I managed to install a brother printer palemoon 28 and latest firefox. I can run all kind of software currently working in precise from within every puppy (and puppy 4.31) 32bit or 64 bit (a 64 bit puppy can chroot a 32 bit environment). I use simple scripts like:

palemoonchroot:

Code: Select all

#!/bin/sh
export LC_ALL=C
mount --bind /dev /mnt/sdb1/cnt/dev
mount --bind /proc /mnt/sdb1/cnt/proc
mount --bind /sys /mnt/sdb1/cnt/sys
xhost +
mount --bind /tmp/.X11-unix /mnt/home/cnt/tmp/.X11-unix
chroot /mnt/sdb1/cnt /usr/bin/palemoon "$@"

cupschroot:

Code: Select all

#!/bin/sh
/etc/init.d/cups stop
mount --bind /dev /mnt/sdb1/cnt/dev
mount --bind /proc /mnt/sdb1/cnt/proc
mount --bind /sys /mnt/sdb1/cnt/sys
mount --bind /mnt/sdb1/cnt/var/run/cups /var/run/cups 
mount --bind /mnt/sdb1/cnt/var/spool/cups /var/spool/cups  
xhost +
mount --bind /tmp/.X11-unix /mnt/sdb1/cnt/tmp/.X11-unix
mount -t tmpfs -o size=10M tmpfs /var/spool/cups
chroot /mnt/sdb1/cnt /etc/init.d/cups start

For internet working in the precise chroot jail you have to copy /etc/resolv.conf in the jail. I wonder if some kind of scripting can be used to minimize the needed jail to run palemoon 28 in puppy 4.31, for example.

[mikeslr]

Hi fred,

Thanks to Mike Walsh's post yesterday, this thread came to my attention. [May have read it before, and had it lost among the extensive data of my flaky memory].

Thanks for the utility. I'll have to study it to the point of understanding.

A while back, after reviewing a post comparing AppImages, Snap and Flatpaks, I wrote, "My take is that using them [AppImages, Snap and Flatpaks] with Puppies as an alternative to SFSes, the advantage lies with AppImages. Indeed, we could even create and host them. Something to be considered if the devs who maintain aufs ever quit, and gyro's overlayfs becomes a necessity. [Or maybe I've misread the reason for overlayfs]. Emphasis supplied. http://murga-linux.com/puppy/viewtopic. ... 66#1000166

My read of https://askubuntu.com/questions/866511/ ... and-others was that, while Puppies could make use of the snaps or flatpaks others create, snaps were too closely tied to Canonical/Ubuntu and flatpaks to the relationship of other 'Big Distros'' package management for Puppy to become extensively involved in their creation and maintenance.

Hence, my favoring AppImages. From your post I've learned that AppImages can be utilized in two different ways: - 'PortableAppsLinux Mode' or 'Chroot mode'

Puppies and DebianDogs being operating systems which by design have lower demands for Random Access Memory than the likes of Ubuntu and Red Hat, I wonder if you have any idea how the RAM demands of an application packaged as an SFS compares to that of the same application packaged as an AppImage in PortableAppsLinux Mode' or 'Chroot mode' ?

[fredx181]

Hi mikeslr,

Hence, my favoring AppImages. From your post I've learned that AppImages can be utilized in two different ways: - 'PortableAppsLinux Mode' or 'Chroot mode'

Well, that are just names I gave it for to separate different ways of utilizing.

The 'Chroot mode' may not work well in all cases (see watchdog's comment above).
If I find the time I'll test more and possibly improve it.
(and testing from others always appreciated of course )

Btw. note that (depending on the complexity of the app) that it may be needed to adjust things manually (see for example my previous post above)

Puppies and DebianDogs being operating systems which by design have lower demands for Random Access Memory than the likes of Ubuntu and Red Hat, I wonder if you have any idea how the RAM demands of an application packaged as an SFS compares to that of the same application packaged as an AppImage in PortableAppsLinux Mode' or 'Chroot mode' ?

I don't know, should be tested, but my guess is that there won't be much difference in RAM usage.

Fred

[watchdog]

This can be used as a useful tool to edit and do little changes to existing AppImages to run in puppy as root. Extract with:

Code: Select all

./appImage-name --appimage-extract

and repack with create-portable32 or create-portable64. I repacked VLC-2.2.8.glibc2.16-x86_64.AppImage to run as root in 64 bit puppies.

[fredx181]

This can be used as a useful tool to edit and do little changes to existing AppImages to run in puppy as root. Extract with:

Code: Select all

./appImage-name --appimage-extract

and repack with create-portable32 or create-portable64. I repacked VLC-2.2.8.glibc2.16-x86_64.AppImage to run as root in 64 bit puppies.

Thanks ! Didn't know about the --appimage-extract option.

[Mike Walsh]

@ Fred:-

Harking back to your post on the 'AppImages in Puppy' thread, where you were saying about the TeamViewer AppImage not working, but that the self-extracting script did, well..... I've just come across the same problem with the humble XVidCap screen-recording app.

Pack it as an AppImage, and even in a pristine, fresh Puppy install, it won't record, citing

Code: Select all

Error:Read-only filesystem

But if you pack it as a 'self-extracter', it's quite happy. I wasn't aware that your script created a read-only filesystem with the AppImages?


Mike.

[fredx181]

Code:
Error:Read-only filesystem


But if you pack it as a 'self-extracter', it's quite happy. I wasn't aware that your script created a read-only filesystem with the AppImages?

That's in general the case with all Appimages, mounted read-only in /tmp

Fred

[fredx181]

*** Update create-portable, v2.0 ***

See changes & fixes, info and some tips at second post:
http://murga-linux.com/puppy/viewtopic. ... 16#1011816
Download links at first post replaced with v2.0

EDIT: few hours later: Ooops... made a mistake, re-uploaded, download links at first post replaced.

Fred

[don570]

I made a fatdog64 package to install an old version of audacious
using a similar technique of storing the libraries in /opt and then
pointing to them.

http://murga-linux.com/puppy/viewtopic. ... 55#1023967
_______________________________________________

[fredx181]

2020-04-21 updated to v2.1

Change is: support for name containing spaces.
For example if Name= in the .desktop file in the appdir is:

Code: Select all

Name=Openshot Video Editor

Then now the created appimage will be named: Openshot_Video_Editor
(previously appimage creation failed when name contained spaces)

Download::
32-bit, extract and run create-portable32 (appimage)
https://dl.dropboxusercontent.com/s/npi ... ar.gz?dl=1 (size: 261K)
64-bit, extract and run create-portable64 (appimage)
https://dl.dropboxusercontent.com/s/6go ... ar.gz?dl=1 (size: 248K)

Replaced download links with v2.1 in first post.

Fred