Using AppImages in Puppy...

Message

fredx181 · #136 Post by **fredx181** » Fri 27 Mar 2020, 13:33

Here's a simple command-line method to modify an existing appimage.
Can be handy in case an appimage doesnt work, e.g. because of missing libs.
It's very simple because an appimage is in fact an SFS, but "injected" with a binary "runtime", below commands use "runtime32" (for 32-bit), change to "runtime64" to create a 64-bit appimage (on a 64-bit OS)
The GUI program from here is using the same method of creating the appimage, but has more options (but not the option to extract an appimage, btw).

Let's assume that the appimage is in /root, replace "<originalappimage>" with the real name of the appimage.
Extract the appimage:

Code: Select all

/root/<originalappimage> --appimage-extract

A directory "squashfs-root" will appear.
Make your modifications inside, e.g. add missing libs or whatever.
Having done that, create a temporary squashfs file named "temp-squashfs.squashfs" from dir "squashfs-root":

Code: Select all

mksquashfs '/root/squashfs-root' temp-squashfs.squashfs  -root-owned -noappend

Extract the attached tarball "runtime.tar.gz" in root, then: (replace "<newappimage>" with preferred name)

Code: Select all

cat /root/runtime32 >> <newappimage> # change to runtime64 for 64-bit

Then create the new appimage by merging temp-squashfs.squashfs with <newappimage>: (use the same name as above for <newappimage>)

Code: Select all

cat /root/temp-squashfs.squashfs  >> <newappimage>

Make the new appimage executable:

Code: Select all

chmod a+x <newappimage>

That's it !

You may want to remove /root/temp-squashfs.squashfs and /root/squashfs-root:

Code: Select all

rm -f /root/temp-squashfs.squashfs
rm -fr /root/squashfs-root

Fred

Mike Walsh · #137 Post by **Mike Walsh** » Mon 30 Mar 2020, 23:40

@ Fred:-

Nice idea, mate, but this method falls flat on its face in the Puppies, I'm sorry to say. The 'Dogs' must have stuff installed that's not native to Puppy itself.....which is a massive pain, because I really want to extract the Openshot AppImages and see just exactly what's inside the buggers!!

Mike.

RedQuine · #138 Post by **RedQuine** » Tue 31 Mar 2020, 09:09

Mike Walsh wrote:I really want to extract the Openshot AppImages and see just exactly what's inside the buggers!!

Have you tried UExtract?

fredx181 · #139 Post by **fredx181** » Tue 31 Mar 2020, 09:31

Hey Mike,

@ Fred:-

Nice idea, mate, but this method falls flat on its face in the Puppies, I'm sorry to say. The 'Dogs' must have stuff installed that's not native to Puppy itself.....which is a massive pain, because I really want to extract the Openshot AppImages and see just exactly what's inside the buggers!!

Which Openshot AppImages ? (so I can try) Extracting appimages works on Puppy (no difference with 'Dogs') (from what I tested), note that you can only extract a 64-bit appimage on a 64 bit OS (and 32 bit only on 32-bit).

EDIT: Just tried extracing the appimage from here: https://www.openshot.org/nl/download/ and indeed doesn't work (unknown option --appimage-extract) which means to me that it's built with a different method than "normal". Btw, it doesn't run either (on BionicPup64).

EDIT2: It can be extracted with "AppimageExtract", so it's has been built the "old" way.
(maybe you still have the AppimageExtract binary, don't know atm where to find it, have to go out now, back later)

Fred

Mike Walsh · #140 Post by **Mike Walsh** » Tue 31 Mar 2020, 11:49

Morning, Fred.

RedQuine's hit the nail on the head (cheers, mate!). Jake (SFR)'s latest UExtract, v4.0, does indeed extract AppImages. I must thank Jake for that; I'd no idea that ability had been added into 'the mix' that UExtract was already capable of handling.....

Y'know, it's hardly surprising this is a strange one to get running. If you study the structure, J.T has gone and put absolutely everything into /usr/bin; binaries, libs, Python, Qt5, etc......the lot. I'm not even sure as it would be possible to re-build this into a working SFS package, for instance.....the construction is so peculiar. It's more like a kind of weird 'hybrid' of old and new.

----------------------------

One of the new guys, O.F.I.N.S.I.S, has uploaded some SFS packages from his own, highly-customized Bionicpup64, here (and subsequent posts):-

http://www.murga-linux.com/puppy/viewto ... 92#1054192

I've tried the final SFS - the biggest, all-in-one job - and yes, it does indeed run in a pristine Bionicpup64, OOTB. What we now need is someone with the patience of a saint (and extreme single-mindedness!) to disentangle the KDEnlive stuff from the Openshot stuff, hopefully resulting in a 'standalone' SFS of current, 2-series Openshot that anyone can just load, and it'll run.....

I don't think that someone is going to be me, somehow... (*shakes head*) Mikeslr, d'you fancy attacking this one with P.A.D.S and a copious supply of coffee...?

Interestingly, while this rather large SFS is loaded, giving you v2.4.1, the very latest AppImage - now up to v2.5.1 - will also run. If you unload the SFS, however, the AppImage doesn't want to know. What I always get is grumblings about missing Qt5 'version' info (?!??), along with a complaint about not finding the 'xdg-icon-resource'. (Huh??) I do not know what this last item is, although I do know from previous experience with older Openshots that every 'item' in the Python side of things seems to require matching with a system lib, and various python binaries.

I have to whole-heartedly concur with Mikeslr on this point; Python is a total bloody nightmare to work with! You can't even run an 'ldd' on it for missing stuff, 'cos Python is just a bunch of scripts.....apart from the framework binaries themselves, there are no individual binaries for it to work with.....

(*Jeez, Louise. Grrrrr.....*

)

A very disgusted Mike.

mikeslr · #141 Post by **mikeslr** » Tue 31 Mar 2020, 15:55

Mike Walsh, "to disentangle the KDEnlive stuff from the Openshot stuff, hopefully resulting in a 'standalone' SFS of current, 2-series Openshot that anyone can just load, and it'll run.....I don't think that someone is going to be me, somehow... (*shakes head*) Mikeslr, d'you fancy attacking this one with P.A.D.S and a copious supply of coffee...?

"

Not me.

O.F.I.N.S.I.S's build has, apparently, overcome the primary reason for NOT simultaneously having both Openshot and KDEnlive one's system: the previous incompatibility of the python modules they employed.

Here's the thing which I've yet to completely get my head around. The computing environment has changed and somewhere along the line of Puppy's evolution something may also have changed; or maybe I always misunderstood. A couple years ago I ran some experiments comparing the amount of available RAM with applications installed as pets, loaded as SFSes or merely linked as portables. At that time having only 512 Mbs of RAM or less was common. The thinking was SFSes were superior to pets because by unloading an SFS it would obviously use No RAM; while a pet, occupying space in a SaveFile would always need some RAM. That concept held true. However, what the exploration revealed was that even the then RAM hog LIbreOffice, however deployed, only required what in today's computing environment is an insignificant amount of RAM WHEN THE APPLICATION WAS NOT IN USE. By way of illustration LibreOffice at that time required 768 Mbs of Space on Storage and/or in a SaveFile: if installed but not opened it only required about 11 Mbs of RAM more than the same Puppy booted to desktop without LibreOffice installed. What's 11 Mbs of RAM when you now have 2 Gb or more? Especially under Bionicpup64 which, itself, requires at least 1 Gb for satisfactory performance.

My recent exploration of nic007's technique of substituting an adrv for a SaveFile reveals similar results. An adrv created from a SaveFile which exceeded 1 Gb had hardly any impact on the available RAM at bootup.

I used to think this phenomena had to do with the creation of inodes which pointed to files on Storage rather than copying them into RAM. But, explorations with using an adrv and removing the USB-Key from which Puppy was booted confirmed william2's proposition that 'everything' was copied into RAM on bootup. So I guess it has to do with caching and buffering --which I don't understand.

At any rate, its hardly likely that removing those files in O.F.I.N.S.I.S' 284 Mb SFS which are only required by KDEnlive would make a significant difference in the amount of available RAM for doing anything.

Mike Walsh · #142 Post by **Mike Walsh** » Tue 31 Mar 2020, 22:28

Hallo, Mike.

Well now; I'm no longer really in the traditional Puppy 'mould', any more. This new hardware has a fast (3.7 GHz) quad-core Pentium Gold 'CPU', with advanced modern instruction sets; currently 8 GB of 2400 MHz DDR4 RAM; I finally have a discrete Nvidia GPU with 2 GB of dedicated GDDR5 VRAM, running with the proprietary Nvidia drivers, some of which I've compiled myself, using Shinobar's Get-Nvidia 1.5.pet.....and over 4 TB of internal storage. (I ripped the Barracuda drive out of the 3 TB external Seagate USB 3.0 drive I had, and added it as a secondary internal drive. Despite this HP mini-tower being physically smaller than ye olde Compaq tower, it seems to have a darned sight more space inside it.....no doubt due to all the components being that much smaller, including the minute slim-line PSU HP have seen fit to saddle it with..!)

Consequently, I'm having even more fun with Puppy now than over the last 5 years.....and the size of packages bothers me even less than it did previously. To that end, and bearing in mind the sheer number of AppImages & portables I've got kicking around, I've taken on board your suggestion from earlier; rather than loading O.F.I.N.S.I.S's humungous SFS package into my existing, general-purpose Bionicpup64 and risking it breaking stuff, I've created a second save-folder, loaded it into that, and made use of all those AppImages to build myself a dedicated, multimedia Puppy around it.

And so, here IS

"MediaPup" 8.0..!

'Clean':-

.....and 'dirty':-

What'cha reckon, huh? Hell, I've got the storage & RAM, and the processing power to do things with it now, so.....why not.

Life's good (all things considered), and I'm having a lot of fun.

Mike.

Mike Walsh · #143 Post by **Mike Walsh** » Wed 01 Apr 2020, 00:18

Wonderful news, boys & girls.

The utterly AWESOME LosslessCut video trimmer/editor is now available as an AppImage. And about time, too!

I've followed this thing from the very early days:-

http://www.murga-linux.com/puppy/viewto ... 112245#top

It's always been built using the 'Electron' framework; this necessarily means it's gonna be large, 'cos Electron is essentially a 'stripped-down' Chromium browser. 'Nuff said.

v1.10.0 was extremely basic, and hardly did much of anything at all. However, its developer, "mifi", released this most recent 'stable' build - v3.17.9 - just 3 days ago.....and it's now stuffed to bursting with tons of goodies, all powered by the amazing ffmpeg.

(In the last 24 hours, mifi has committed seven further 'point releases' to his project page over at Github! I think it's fair to say this lad has got the bit firmly between his teeth, and is full of ideas. All credit to him, I say, especially when he puts out such an amazing app as this one.)

This release runs OOTB under Bionicpup64, and is just one of the 'stars' of my newly put-together 'MediaPup 8.0' (see my post above). No, it's not a new Puppy, but it was inspired by a comment Mikeslr made during the last day or two about creating a separate save-folder for running the 2-series Openshot SFS package O.F.I.N.S.I.S has put together recently.....this is to do with multiple Python 'issues', nothing else.

I'd got a whole stash of multimedia-type AppImages & portable apps sitting around doing nothing, so I thought I'd put together a dedicated Puppy and put 'em to good use at long last.....

----------------------------------

This is available as either a 'straight' Electron package:-

https://github.com/mifi/lossless-cut/re ... ux.tar.bz2

.....or an AppImage:-

https://github.com/mifi/lossless-cut/re ... x.AppImage

As with everything these days, these are now 64-bit only. They run OOTB under Bionic; I'm going to try this release in Xenialpup64 tomorrow, but I'm not hopeful.....I think the older glibc will be the killer. We'll see.

In all cases, this needs to be started with the

Code: Select all

--no-sandbox

....'flag'.

EDIT:- My fears were unfounded. This fires straight up under Xenialpup64, so.....nice one.

Mike.

tallboy · #144 Post by **tallboy** » Thu 02 Apr 2020, 00:00

Mike wrote:Well now; I'm no longer really in the traditional Puppy 'mould', any more. This new hardware has a fast (3.7 GHz) quad-core Pentium Gold 'CPU', with advanced modern instruction sets; currently 8 GB of 2400 MHz DDR4 RAM; I finally have a discrete Nvidia GPU with 2 GB of dedicated GDDR5 VRAM, running with the proprietary Nvidia drivers, some of which I've compiled myself, using Shinobar's Get-Nvidia 1.5.pet.....and over 4 TB of internal storage.

You #%¤@ traitor!

Mike Walsh · #145 Post by **Mike Walsh** » Thu 02 Apr 2020, 09:38

tallboy wrote:
Mike wrote:Well now; I'm no longer really in the traditional Puppy 'mould', any more. This new hardware has a fast (3.7 GHz) quad-core Pentium Gold 'CPU', with advanced modern instruction sets; currently 8 GB of 2400 MHz DDR4 RAM; I finally have a discrete Nvidia GPU with 2 GB of dedicated GDDR5 VRAM, running with the proprietary Nvidia drivers, some of which I've compiled myself, using Shinobar's Get-Nvidia 1.5.pet.....and over 4 TB of internal storage.

You #%¤@ traitor!

Hah! Hark who's talking....

Perhaps a 'traitor' where hardware's concerned, Olaf, but my God! Pup absolutely screams on this thing.....and after trying out I don't know HOW many other distros over the last few years, I always return home to the sanity of the kennels, and the support of an amazing community.

(I'm loyal, if nothing else mate....

)

Mike.

tallboy · #146 Post by **tallboy** » Thu 02 Apr 2020, 16:27

It was stricktly meant as a hardware joke, Mike. I don't think anyone can accuse you of not being a loyal 'Puppyteer', they dance to your moves!

I hope you are extra careful these days, disaster lurks at home, if you get infected. Wear gloves, use facemask, wear protection glasses, wash hands. This is bad!

Mike Walsh · #147 Post by **Mike Walsh** » Thu 02 Apr 2020, 16:35

@ tallboy:-

^^^ + 1!!! Oh, aye....

tallboy wrote:I hope you are extra careful these days, disaster lurks at home, if you get infected. Wear gloves, use facemask, wear protection glasses, wash hands. This is bad!

You too, mate. Stay sharp.....and stay 'safe'. Take care!

Mike.

watchdog · #148 Post by **watchdog** » Thu 02 Apr 2020, 19:20

tallboy wrote: I hope you are extra careful these days, disaster lurks at home, if you get infected. Wear gloves, use facemask, wear protection glasses, wash hands. This is bad!

The more bad thing is that you can go out with your dog for a walk but not with your children.

step · #149 Post by **step** » Fri 03 Apr 2020, 22:02

Get more dogs!

watchdog · #150 Post by **watchdog** » Sun 19 Apr 2020, 13:57

Cryptomator 1.5.0 encryption 256 AES tool distributed as AppImage:

https://cryptomator.org/downloads/

Only 64 bit. Working in quirkyApril-light64 by jrb.

Mike Walsh · #151 Post by **Mike Walsh** » Wed 20 May 2020, 01:04

Evening, kiddiwinks.

Just a quick one for y'all tonight. Mikeslr has dug up a very neat little AppImage for checking codecs of films, audio tracks, anything media-related, really.....in both 32- & 64-bit versions. Fires straight up in most relatively modern Puppies, OOTB.

MediaInfo

You can find the link for it here:-

http://www.murga-linux.com/puppy/viewto ... 56#1058456

Thanks, Mike..!

T'other Mike.

tallboy · #152 Post by **tallboy** » Wed 20 May 2020, 22:30

watchdog wrote:The more bad thing is that you can go out with your dog for a walk but not with your children.

There are always solutions to such problems...

jplt3 · #153 Post by **jplt3** » Sun 31 May 2020, 11:39

Find today that Molotov : French tv player has an appimage

https://www.molotov.tv/download

Code: Select all

Don't run as root so do in a console where your appimage is :
./molotov.AppImage --no-sandbox

To be more secure install firejail it's an easy way to use sandbox programs :

Code: Select all

pkg a firejail

And run your molotov :

Code: Select all

firejail --noprofile ./molotov.AppImage --no-sandbox

I have done this on :

Code: Select all

cat /etc/os-release 
NAME=Puppy
VERSION="8.0"
ID=puppy_bionicpup64
VERSION_ID=8.0
PRETTY_NAME="bionicpup64 8.0"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:puppy:puppy_linux:8.0"
HOME_URL="http://puppylinux.com/"
SUPPORT_URL="http://www.murga-linux.com/puppy/index.php"
BUG_REPORT_URL="https://github.com/puppylinux-woof-CE/woof-CE"

Enjoy

memo · #154 Post by **memo** » Sun 31 May 2020, 14:33

jplt3 wrote:Find today that Molotov : French tv player has an appimage

https://www.molotov.tv/download
Code: Select all
Don't run as root so do in a console where your appimage is :
./molotov.AppImage --no-sandbox
To be more secure install firejail it's an easy way to use sandbox programs :
Code: Select all
pkg a firejail

hi, I installed firejail from the ppm but it gives error when I try to lunch ut. screenshot;

http://i.imgur.com/tc7is0d.png

Semme · #155 Post by **Semme** » Sun 31 May 2020, 14:54

This should take care of the error in your image so long as you can interpret Rosika's workaround.

BTW, you don't really wanna run Slimjet. If however you insist, you wanna run "flashpeak-slimjet," NOT slimjet.

A whole bag-O-goodies await...

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Using AppImages in Puppy...