AppImages Snaps flatpaks CDE &c - General Information: NOT ABOUT SPECIFIC APPS

[gyrog]

One of the issues with things like appimages, sfs files, etc..., is how do you update them?
The normal answer is, doanload a new version.

But the appimage folk seem to like a thing call "zsync", which is an updater of binary files by only downloading the blocks that are different between the old version and the new version, a kind of "rsync" over the net.
I've been experimenting with it with my FrugalPup appimages.
It appears to work.

To update 'FrugalPup-i386.AppImage', download 'FrugalPup-i386.AppImage.zsync' into the same directory as 'FrugalPup-i386.AppImage', then run:

Code: Select all

zsync -i FrugalPup-i386.AppImage FrugalPup-i386.AppImage.zsync

The ".zsync" file was created with:

Code: Select all

zsyncmake -e -u http://www.fishprogs.software/puppy/frugalpup/files/FrugalPup-i386.AppImage FrugalPup-i386.AppImage

Note1: I installed "zsync" via PPM, this includes "zsyncmake"
Note2: This won't work with "mediafire", so I had to use an ordinary "HTTP" server.
Note3: "zsync" could just as easily be used for ".sfs" file, ".iso" files, ".zip" files, etc...

[fredx181]

Hi All,

Although the last few posts have been about easing the work-load by using already existent AppImages rather than such other package formats as SFSes, this seems a good place to note fredx181's "Create AppImage" application. You'll find its thread here, viewtopic.php?f=106&t=590.

And as I haven't had breakfast yet and my mind is wandering, just to note (a) fred's application not only can create portable AppImages, it can also create --with limitations-- applications that work in 'chroot mode'; [plus, as Mike Walsh noted, generate Rox-Apps as a byproduct]. And (b) Mike Walsh's post earlier in this thread about starting AppImages via wrappers, viewtopic.php?p=16465#p16465.

And lastly, I don't recall there having been much testing or discussion about the use of fred's application's 'chroot mode'. Seems there may be circumstances where it might be just what's needed. But at this point the train of thought gets derailed. So time to have breakfast.

The 'chroot mode' can be considered as "plan B" when an app is very complex and doesn't work well with the standard "Portablelinuxapps mode".
In fact the 'chroot mode' works very similar as when loading an SFS, as it's merging the files (included in the appimage) with the 'root system' ( / ) by using unionfs-fuse in a "jail" (chroot).

Fred

[gyrog]

Ok, I've managed to make, run and update an appimage.

Has anyone had success at doing any of those things with a flatpak or snap?
If so, I would like to know how you did it, please .

[gyrog]

The more I play with my FrugalPup appimge, it seems that this could be useful as a replacement for 'sfs_load'.
My idea is based on the "load sfs, execute application, unload sfs" I've come across in the forum.
As well as an idea to "ativate" and "deactivate" a downloaded application rather than "load" and "unload".

The issue with an appimage file, is integrating it into the Puppy menu.
I have thought of a way to implement this, using only the appimage file itself, no extra ".pet" required.
I will implement this with my FrugalPup appimage.

[gyrog]

See viewtopic.php?p=28584#p28584 for a more information on a FrugalPup appimage file, that implements an internal "--activate" and "--deactivate".

So this technology is looking closer to be a "replacement" for "sfs_load" that will survive the transition to overlayfs, since it doesn't touch the stack structure.
Yes, I know that no one else believes that the sky will fall, but I see as it as a real possability, that should not be ignored.

My next trick is to produce an "sfs_load" like GUI utility to "activate/deactivate" these things.

The trick after that is to "attack" one of @mikewalsh's magnificent "portable" apps in the form of "Firefox" and convert it to an actual appimage. From looking at it's internals, it should not be very difficult.

Which then poses the question, to appimage or not?
The problem is that the @mikewalsh way of producing a "portable" app is a lot like an extracted appimage, so it could possibly be integrated into Puppy in a similar manner, i.e. a few symlinks in appropriate places, but not very many, would make them accessible via the Puppy menu, just like a mounted .sfs file.

The advantage of an appimage is that it's a single compressed file that's downloaded and used as is, in it's compressed form, a bit like a .sfs file.
And it can be efficiently updated with the zsync utility.

A downside of the @mikewalsh approach is that afer downloading a single .tar.gz file, it has to be extracted to a directory, (or at least that's what I did), thus not compressed when in use. Although this might be considered a plus.
The files are just sitting in a directory, so are very available, unlike in a package like appimage.
So Firefox can do it's own updating on the files, (as it did when I first ran my copy of "Firefox Quantum").
So any "activate/deactivate" utility could be implemented purely as an external script, but doing so would impose a certain internal structure so that the utility could find the relevant files in each application.

Hmmmm... we live in interesting times.

Apologies, if It's someone else I should be "blaming", but the "FireFox" I downloaded was from @mikewalsh's repository, as mentioned in his signature.

[mikewalsh]

@gyrog :-

I doubt it's really a case of 'blaming' ANYONE, TBH.

I adapted an approach Fred came up with. Fred himself found the basic 'portabilizing' script online; it had been floating around the 'net for donkey's years. Someone originally developed an approach to a 'portable' browser back in the late NetScape Navigator days, when it was transitioning into early Firefox.

I'll be the first to admit that my approach is far from ideal. Currently, I'm running a 9th-gen, 3.7 GHz quad-core Pentium Gold, 32 GB RAM, with over 5 TB of assorted storage, and a discrete GPU. It's hardly a typical Puppy box if I'm honest, and what works fine for me isn't necessarily ideal for those with more modest hardware.

My technique is as follows; on a partition of my primary 1 TB drive, I keep all my portable applications. Any time I set-up a new Puppy, I've built a .pet that consists largely of nothing but custom Menu Entries. This populates the Menu with all the portable apps that I use on a regular basis, firing up all of these from an auto-mounted, external partition.

This is the thing about these, and what makes them truly portable; using the "read-link" trick, you can run these from a flash-drive.....and hence, 'share' between multiple Puppies on multiple machines.

That's the way I do it; 'sharing' single, self-contained applications between multiple occupants of the kennels.

Mike.

[gyrog]

@mikewalsh,

I'm currently using the "Quantum Firefox" portable applicatioin, that I downloaded from your collection on Google Drive, as a test case for 2 utilities, 'activate-portable' and 'deactivate-portable', and they work.

'activate-portable' creates a symbolic link to the '.DirIcon' in /usr/share/pixmaps/', a symbolic link to 'LAUNCH' in a binary directory that appears in the $PATH, and generates a simple '.desktop' file in /usr/share/applicatiions/.
This makes the portable application visible in the desktop menu, and as a simple console command.
It also writes a list of any files it adds to Puppy to "$HOME/.packages/<package-name>.portable.files".

'deactivate-portable' reads the selected "$HOME/.packages/<package-name>.portable.files" file and removes all the files listed there, the result is Puppy returns to the way it was.

I will be releasing them soon, but 'activate-portable' still needs a little tweking, the generated ".desktop" file is still a little limited.
My aim here is to make all these "portable-applications" as easily available to users as are ".sfs" files via "sfs_load".

Note: Your type of portable application is very flexible, I wanted to place the firefox application on my SSD, but the "profile" on my HD, so I just edited the 'firefox32/ff' to specify a profile in the place I wanted it to be, great.

So, are most of the portable applications in your collection executed with "<directory>/LAUNCH"?
Do many have a '.DirIcon' file?

[mikewalsh]

@gyrog :-

Yep, I like to use a .DirIcon in ALL my portables (looks a wee bit more 'professional', y'know?)

And they ALL use a 'LAUNCH' script. (The Chromium 'clones' include TWO 'LAUNCH' scripts; one 'normal' one, which tells the browser to use the included 'lib' directory, and a second marked 'LAUNCH_NL', for recent Puppies, which use newer included libs by default. If you use the included 'lib' directory with these, you get versioning conflicts.) Hence, the two scripts - and wrappers.

A thought; might it be simpler to just generate a Menu entry directly in ~/.jwmrc itself?

(And please; DO give Fred credit for using the basic launch script in its original 'ff' configuration..! If he hadn't published that first portable, my own 'portable-app' building would have never taken off the way it has. Credit where credit's due.)

Mike.

[fredx181]

Hi Mike, I had a look at your Quantum-portable64, here: https://drive.google.com/drive/folders/ ... p5CDmbVxsb
The LAUNCH script is a broken symlink for me:

Code: Select all

drwxr-xr-x 10 root root 4096 aug  2  2020 firefox64
lrwxrwxrwx  1 root root   60 aug  2  2020 LAUNCH -> /mnt/sda3/SYSTEM/BROWSERS/64-bit/Quantum-portable/firefox/ff

Should be a relative symlink, don't you think ?

Fred

[mikewalsh]

@fredx181 :-

Hallo, Fred.

Ah, ya caught me out again! I've downloaded & had a look at it; that's not even a particularly new version.....and it appears it was packed just at the moment an update was in progress, because the 'firefox64' directory is twice the size it should be!

I'm guessing that was a "last thing before bedtime" job, when I was probably half-asleep.

(You also need to understand that I copy these across from my main browsers partition to a work area. I then modify, and test with my own profile, etc, still in place. Unfortunately, I don't always remember to remove this stuff and leave 'em in pristine condition before packing 'em..... )

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

I've downloaded the current version, re-built, re-packed & re-uploaded it again. Everything's as it should be now, including the current 'LAUNCH' script ( I quit merely sym-linking some time ago, so that's how I know that's been there a while). I just now, for the first time, experimented with tar.bz2 instead of my normal tar.gz. Wow. That's, um, quite an improvement.....like about half the size, so I would guess it's close on double the compression..?

I think I shall use that permanently from now on. I can see why Mozilla use it themselves; Jake (SFR) includes this in Packit, so it's no hardship to use.

Mike.

[fredx181]

Here's a way to create an appimage from portable firefox directory e.g. as created from install script here: viewtopic.php?f=90&t=96
Not sure if it's useful for anyone, for me it's nice experiment anyway to explore appimage creating.
Latest 64-bit at this time is firefox_89.0.1_64
Attached "cr-appimage-firefox.tar.gz" contains: script "cr-appimage" and runtime32, runtime64 binaries.

Extract it in the firefox directory e.g. firefox_89.0.1_64 (containing firefox, firefox-bin etc...)
(for mikewalsh's portable Quantum it may be named "firefox64")

Then run from terminal standing in this firefox directory: ./cr-appimage
And in the parent dir the portable appimage "Firefox-Portable32" or "Firefox-Portable64" will be created (depending on your architecture 32-bit or 64-bit).

When running it, the "profile" dir will be next to the appimage in same directory.

Advantage of an appimage is that it takes less space, as it is compressed (in fact a .squashfs).
Disadvantage may be that firefox cannot update itself, since the appimage is mounted read-only (but some may prefer that it cannot be updated).

Here's 64-bit "Firefox-Portable64" (v89.0.1) made this way, make it executable before running:
https://drive.google.com/uc?export=down ... t6770hT6_3

I guess with some simple edits in the cr-appimage script it can work for other portable browsers from mikewalsh too.

@mikewalsh OK, good that you fixed your Quantum-portable share.

Fred

[mikewalsh]

@fredx181 / @gyrog :-

Following Fred's remarks above, I thought I'd take a crack at creating an Opera AppImage, using the current release. It needs more than just the cr-appimage script editing, but not that much more. It's certainly "do-able".

- I've created a directory, "Opera-AppImage", into which I copied the main 'opera' directory from the portable.

- The 'LAUNCH' script is the main 'executable' for the portables, and is what starts the ball rolling. I've moved this inside the /opera directory, and edited paths to suit.

The edited 'cr-appimage' script now reads as follows:-

Code: Select all

#!/bin/bash

# Not running from terminal ?
tty -s;
if [ $? -ne 0 ]; then
	exit 0
fi

if [ "$(uname -m)" = "i686" ]; then
# set appimage name
NAME="Opera-Portable32"
# set runtime name
RUNTIME=runtime32
elif [ "$(uname -m)" = "x86_64" ]; then
# set appimage name
NAME="Opera-Portable64"
# set runtime name
RUNTIME=runtime64
fi

# set profile name (will be in same dir as appimage)
PROFILE=PROFILE

APPDIR="$(dirname "$(readlink -f "$0")")"
#cd "$APPDIR"

cr_appimage () {
SQUASH="$(dirname "$1")/$(basename $2).squashfs-$RANDOM"
mksquashfs "$1" "$SQUASH" -root-owned -noappend
cat "$APPDIR"/$RUNTIME >> "$(dirname "$1")/$(basename $2)"
cat "$SQUASH" >> "$(dirname "$1")/$(basename $2)"
echo
echo "Making $(dirname "$1")/$(basename $2) executable..." 
chmod a+x "$(dirname "$1")/$(basename $2)"
rm -f "$SQUASH"
echo
echo "Done !"
}

    if [ -f "$(dirname "$APPDIR")/$NAME" ]; then # check if appimage already exists
read -p "$(dirname "$APPDIR")/$NAME already exists, replace it ? (ENTER=yes) (Y/n)" choice
case $choice in
  y|Y|"")
rm -f "$(dirname "$APPDIR")/$NAME"
;;
  n|N)
exit
;;
esac
    fi

# Create AppRun
echo '#!/bin/bash
if [ -z "$APPIMAGE" ]; then
echo "This script will work only from already created Appimage"
echo "Exiting..."
sleep 2
exit
fi
#LAUNCHDIR="$(cd "$(dirname "$0")"; pwd)"
LAUNCHDIR="$(dirname "$(readlink -f "$0")")"
mkdir "$(dirname $APPIMAGE)"/'$PROFILE'

LD_LIBRARY_PATH="$LAUNCHDIR/:$LAUNCHDIR/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" "$LAUNCHDIR/LAUNCH"
' > "$APPDIR/AppRun"
chmod +x "$APPDIR/AppRun"

# create portable appimage
cr_appimage "$APPDIR" "$(dirname "$APPDIR")/$NAME"

Line 64's 'LD_LIBRARY_PATH' points to the portable's 'lib' directory, and to the 'LAUNCH' exec script. I've removed the clause with the '-profile' switch, 'cos that's exclusive to the 'zilla browsers. The Chromium 'clones' specify their profile directory within the wrapper.

The opera-pup 'wrapper' now reads as follows :-

Code: Select all

#!/bin/sh
#
# Launcher for Opera browser
#
HERE="$(dirname "$(readlink -f "$0")")"
#
LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} 
#
"$HERE/opera" --user-data-dir="$(dirname $APPIMAGE)"/PROFILE --start-maximized --disable-infobars --no-sandbox "$@"

The wrapper uses

Code: Select all

HERE="$(dirname "$(readlink -f "$0")")"

.....and the '--user-data-dir' clause, specifying the profile location, reads like this in the 'portables' :-

Code: Select all

--user-data-dir=$HERE/PROFILE

The AppImage, on the other hand, has as you see above for profile location :-

Code: Select all

--user-data-dir="$(dirname $APPIMAGE)"/PROFILE

Posting from it now, running from a small 16 GB SanDisk Cruzer 'Fit' flash-drive. The whole thing was copied over here, followed by deletion of the original 'opera' working directory, then copying the full Opera profile across from its usual, sym-linked 'remote' location. Good idea, putting the profile directories at the same level as the AppImage..! Makes things very much easier.

The 'Opera-AppImage' directory:-

.....and contents:-

Mike.

[fredx181]

Hi Mike. Nice!

You could as well leave the "LAUNCH" script alone, only edit cr-appimage, the create AppRun part then (untested):

Code: Select all

# Create AppRun
echo '#!/bin/bash
if [ -z "$APPIMAGE" ]; then
echo "This script will work only from already created Appimage"
echo "Exiting..."
sleep 2
exit
fi
#LAUNCHDIR="$(cd "$(dirname "$0")"; pwd)"
LAUNCHDIR="$(dirname "$(readlink -f "$0")")"
mkdir "$(dirname $APPIMAGE)"/'$PROFILE'

LD_LIBRARY_PATH="$LAUNCHDIR/:$LAUNCHDIR/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" "$LAUNCHDIR/opera" --user-data-dir="$(dirname $APPIMAGE)"/PROFILE --start-maximized --disable-infobars --no-sandbox "$@"
' > "$APPDIR/AppRun"

[fredx181]

Good idea, putting the profile directories at the same level as the AppImage..! Makes things very much easier.

Probably not many people know about this feature and I've posted earlier about it in the old forum:
For "standard" appimages you can create a directory "AppImageName.home" next to "AppImageName" and the config/cache files will go in there.
For example I have a "Spotify-64" appimage and at the same level folder "Spotify-64.home", contains all configs that normally go in e.g. ~/.config or/and ~/.cache.

2021-06-22-230213_281x138_scrot.png (9.4 KiB) Viewed 6026 times

Fred

[mikewalsh]

@fredx181 :-

Mm. I now remember why I don't use browser AppImages. Not of the 'clones', anyway.

I'm a huge sci-fi nut.....and I have a NetFlix a/c. NetFlix won't run with a browser that's been turned into an AppImage.

All the 'clones' now appear to use an auto-run 'location' script for the Widevine DRM module, employing the 'tee' command, very similar to what seaside originally developed for Opera-portable. This determines the exact location of libwidevinecdm.so every time the browser fires up, so websites that make use of it can always find it.

AppImages run 'read-only'.....and always mount in /tmp. The 'auto-locate' script can't find WideVine from here, because 'tee' can't function; it needs to be able to write stuff. And that's why they don't work for me....

(*sigh...*)

Yes, they DO work. But for my use-case, they don't work the way I want them to.

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

EDIT:- Interestingly, NetFlix functions fine with the Firefox-portable. I think this is because with Firefox, the Widevine module is located within the profile. With the 'clones', Widevine is located within the main directory.......and this is the part that gets mounted 'read-only' in /tmp.

Unfortunately, no amount of scripting is going to change this with the 'clones'. Yes, you COULD place the Widevine stuff in the profile, but you'd be wasting your time; the browser is hard-coded to expect to find WideVine in the main directory, and that's the only place it will look for it. Short of re-compiling the browser with modifications, there's no way round it....

Which is a bit of a bugger, really. And why, although Firefox is not my browser of choice, I've always admired Mozilla's approach to how they've actually implemented Widevine. Especially the way you can add/remove it just with the tick of a checkbox; like Puppy's JWM 'PuppyPin' file for desktop layout, this function is written to in real-time, and doesn't need a browser re-start to make it work. I wish Google would consider doing something like this, because it would make the browser one hell of a lot more flexible.

Mike.

[gyrog]

(And please; DO give Fred credit for using the basic launch script in its original 'ff' configuration..! If he hadn't published that first portable, my own 'portable-app' building would have never taken off the way it has. Credit where credit's due.)

@fredx181, Thanks for starting this whole "portable-application" thingo. It's giving me a lot to think about.

Note: I'm using the 32bit version of "Firefox Quantum" for my testing, and haven't found any absolute symbolic links.
Though it did self update the first time I ran it.

[gyrog]

And they ALL use a 'LAUNCH' script. (The Chromium 'clones' include TWO 'LAUNCH' scripts; one 'normal' one, which tells the browser to use the included 'lib' directory, and a second marked 'LAUNCH_NL', for recent Puppies, which use newer included libs by default. If you use the included 'lib' directory with these, you get versioning conflicts.) Hence, the two scripts - and wrappers.

If I find both 'LAUNCH' and 'LAUNCH_NL', I'll give the user a choice of which one the integration should link to.

A thought; might it be simpler to just generate a Menu entry directly in ~/.jwmrc itself?

Firstly, I don't know how to do that.
Secondly, if there is a '.desktop' file in '/usr/share/applications' and the user does a 'fixmenus' for any reason, the item my utility put in the menu will remain.
Thirdly, I've got the whole generation of a simple '.desktop' file working Ok.

[gyrog]

On the whiole issue of doing "portable-applications" as an appimage or as a directory, I's still undecided.

The advantage of using a directory is that it is so simple, and so flexible, and things like Firefox updating still work fine.
And it could be updated to a new release by simply releasing an update ".tar.bz2" file that contains only the files that are changed.
But, the files are not compressed while in use.
And while it works fine on a Linux partition, it may struggle elsewhere.
Also if we want utilities like my 'activate-portable' to work reliably, we may need to have a bit of a pattern in the structure, e.g. always using 'LAUNCH' or 'AppRun' as the "kick-it-off" script.

The advantage of using an appimage, is that the files are compressed, not just for downloading, but also in use.
You just download it and use it.
Because it is just a single file it will probably work on any filesystem.
Updating, can be very efficient if the "zsync" method is used, otherwise we have the same updating issues we currently have with .sfs files. It does work, I have it working for my FrugalPup appimage. (Although we could possibly use "zsync" for our current .sfs files.)
But it's more difficult to get at the files inside it, if you are writing an "integration" script.
Unfortunately the integration solution provided by the appimage folk will probably not work very well on Puppy, since Puppy does not seem to fully implement xdg.

Both of these work well with a single application in a single file/directory, but have some difficulty with a multi-application thing like FrugalPup.

Neither of these make any changes to the frugal install stack, so it won't matter if it's "aufs", "overlayfs", or there is no stack.

[rockedge]

Firstly, I don't know how to do that.

It is pretty simple once you get the hang of it. Open /root/.jwmrc and look a the sections that make the menus and copy what you need and modify it.

[fredx181]

@fredx181 :-

Mm. I now remember why I don't use browser AppImages. Not of the 'clones', anyway.

I'm a huge sci-fi nut.....and I have a NetFlix a/c. NetFlix won't run with a browser that's been turned into an AppImage.

All the 'clones' now appear to use an auto-run 'location' script for the Widevine DRM module, employing the 'tee' command, very similar to what seaside originally developed for Opera-portable. This determines the exact location of libwidevinecdm.so every time the browser fires up, so websites that make use of it can always find it.

Are you sure about that ?
I tested by making a Chrome appimage (the same way as we did above, with profile dir at the same level) and playing DRM content works for me.
Widevine is installed in the "profile" folder and "latest-component-updated-widevine-cdm" shows the correct location, I have both in /root (profile and Chrome appimage).

2021-06-23-180526_669x197_scrot.png (23.28 KiB) Viewed 5972 times

Even when I move the appimage + profile dir to another location, it's still OK and "latest-component-updated-widevine-cdm" shows the new location.

EDIT: I don't use "auto-run 'location' script", without it works OOTB for me (maybe Chrome is an exception... ?).
EDIT2: I see now, checked your Opera-portable, and noticed your workaround to get Widevine working, nice work, btw.

Fred

[mikewalsh]

@fredx181 :-

Hiya, Fred.

Are you sure about that ?
I tested by making a Chrome appimage (the same way as we did above, with profile dir at the same level) and playing DRM content works for me.
Widevine is installed in the "profile" folder and "latest-component-updated-widevine-cdm" shows the correct location, I have both in /root (profile and Chrome appimage).

Hmm. News to me. I didn't think you could do that. OK; where exactly did you put the WidevineCdm directory? I assume, from the sound of things, that you moved it out of the main directory and into the profile.....yes? Or did you leave it where it was?

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

No, Opera was not a very good one to try this with. The Opera devs have hard-coded it to always look in the /opt/google/chrome directory....in other words, they 'pinch' Google's Widevine. In the normal course of things, they don't supply it. The way I did it was a development of a workaround the guys on the Opera forum came up with; they'd been tearing their hair out for months trying to make it work.

There ARE location scripts for both Widevine AND libffmpeg in the 'resources' directory, but seaside & I found out that it doesn't matter where you set the path to, Opera promptly ignores your selection and looks where IT seems to think things will be.....

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

Have you got Chrome running-as-spot.....or is it running as root?

Mike.

[fredx181]

Hmm. News to me. I didn't think you could do that. OK; where exactly did you put the WidevineCdm directory? I assume, from the sound of things, that you moved it out of the main directory and into the profile.....yes? Or did you leave it where it was?

No, I didn't move anything, I guess Chrome did itself move it to the profile dir at the point of where I tried to play DRM content (spotify web player), I think I restarted it (or twice) before it actually worked.
Perhaps best that you try the chrome appimage yourself, here it is, Chrome64:
https://drive.google.com/uc?export=down ... sp9GMEeOoH

EDIT: i ran it as root

Fred

[mikewalsh]

@fredx181 :-

Heh. They say great minds think alike, don't they?

I've just done the same, actually. Used the "--test-type" switch to permit running as root, and built the whole thing similar to how I did Opera yesterday. NetFlix just fires straight up and plays stuff, no issues.

Like I said, Opera's NOT a good one to do this with, because of the incredibly "fiddly" way in which it accesses DRM....

Might try Iron next.

Mike.

[fredx181]

Hi Mike, great that it works for you too.

Like I said, Opera's NOT a good one to do this with, because of the incredibly "fiddly" way in which it accesses DRM....

Another surprise for you maybe, I just ran "opera-pup_nl" (instead of the LAUNCH script) in your Opera-portable and DRM content plays for me.
So it seems to me that there's no need for the symlinking done in LAUNCH.
AFAICS Opera handles it different than Chrome, I have /mnt/sda5/Opera-portable and in '/mnt/sda5/Opera-portable/opera/PROFILE/WidevineCdm/latest-component-updated-widevine-cdm' it shows:
{"Path":"/mnt/sda5/Opera-portable/opera/WidevineCdm"}
Unfortunately an Opera appimage won't work for playing DRM content because the mountpoint in /tmp is always named different everytime you launch it.
EDIT: However the content of 'latest-component-updated-widevine-cdm' is updated after started the appimage, e.g.:
{"Path":"/tmp/.mount_Opera6pDdYAw/WidevineCdm"}

Fred

[mikewalsh]

@fredx181 :-

Ooh, I have to say, this is pretty neat. Yes, indeedy.

At home here, my bedroom is right next door to Mama's. She often sleeps in her recliner chair in the front room, but will, on occasion, sleep next door.

I tend to be far more of a 'night owl' than she is. She'll turn in around 11-ish, with me it's more like 2 am. Since I watch a fair bit of NetFlix late at night, this means headphones. Now; it probably shouldn't happen, but every time I switch any Puppy to use the headphone's built-in sound card, I have to completely re-build the Retrovol layout when I switch back, because it never retains it.....despite having a wee script to 'backup' Retrovol's config file in /root.

I digress.

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

I set-up a Xenial64 chroot, some time ago, to run more up-to-date items in Quirky64 'April' 7.0.1 (this is my main 'daily driver'.....and is Tahrpup-era, or thereabouts.)

Quite by accident - just playing around, one night - I found out that if I plug the headphones in, then use the chroot's Alsa Sound Wizard, I can get the headphones to work in the chroot, then simply switch back to 'bare metal' Quirky and the normal sound set-up remains as it was. Long story short, I've set-up an Iron64-portable, FreeTube-portable, and a VLC RoxApp somebody put together a while back (think it was watchdog, not sure) inside the chroot for late-night media entertainment when using the headphones.

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

I tried some time ago to get my 'standard' Chrome-portable to run from the chroot, but for some reason it balked at running from the included, self-contained mini-'spot' directory it uses. Just for the hell of it, I tried running the Chrome-Portable64 AppImage that I built earlier on, that runs as /root....

Damned if it doesn't work perfectly..!! So; I owe ya one, Fred.

(It's very unpredictable, TBH; some things run better from the chroot than they do on 'bare-metal'. Others actually work better in Quirky (surprisingly) when you might in fact expect them to work better in the chroot, given it uses a newer glibc, dependencies, etc, etc. This way, I have the options to experiment in both directions.....)

Cheers, mi amigo!

Mike.

[fredx181]

Ha, great ! You're welcome Mike !

Been experimenting to get Opera appimage work with playing DRM content, quess what ? Success! Here it is, Opera64:
https://drive.google.com/uc?export=down ... mMg-A91J2R
Made from your Opera-portable share.
Small addition in AppRun, create "latest-component-updated-widevine-cdm" with correct path before starting Opera:

Code: Select all

mkdir -p "$(dirname $APPIMAGE)"/profile/WidevineCdm
echo '{"Path":"'$APPDIR'/WidevineCdm"}' > "$(dirname $APPIMAGE)"/profile/WidevineCdm/latest-component-updated-widevine-cdm

(so you get something like: {"Path":"/tmp/.mount_Opera6HP1UfI/WidevineCdm"})

The "lib" folder I left out, it gave an error when setting LD_LIBRARY_PATH=...... pointing to it, works well for me without it.

EDIT:

No, Opera was not a very good one to try this with. The Opera devs have hard-coded it to always look in the /opt/google/chrome directory....in other words, they 'pinch' Google's Widevine.

Apparently this has been changed/fixed, as it works OK for me setting the path...

Fred

[williams2]

@mikewalsh experimented with tar.bz2 instead of my normal tar.gz

One way to create a bz2 file from a gz file:

Code: Select all

# ll xen*
-rwxr-xr-x 1 166M Jun 24 23:32 xen75save.tar.gz
# gzip -cd xen75save.tar.gz | bzip2 -9 > xen75save.tar.bz2
# ll xen*
-rw-r--r-- 1 165M Jun 24 23:40 xen75save.tar.bz2
-rwxr-xr-x 1 166M Jun 24 23:32 xen75save.tar.gz
#

Note: the original gz file was 166M,
the new bz2 file is 165M.

bzip2 works best with text data.

bzip2 is slower than gzip to compress and to decompress.

bzip2 -9 is maximum compression.
It may compress slightly more, but it may be somewhat slower.

Attached: A simple script to create a bz2 file from a gz file.
Usage: gz2bz afile.gz

[gyrog]

Thanks @mikewalsh and @fredx181 for this portable applications stuff.

I've resolved my issue with how to release applications in a Puppy that might have to live without aufs.

If applications are released as ".AppImage" files, they are compressed for downloading, and can be used as is,
without disturbing the frugal stack, as a traditional ".sfs" file would.
But if more flexibility is need by the user, then the ".AppImage" file can be extracted and used as a directory style portable application,
again without disturbing the frugal stack.

And either of these ways can be integrated into Puppy as easily as a ".sfs" file can be with 'sfs_load',
using a 'PortableActivate' utility, viewtopic.php?p=29183#p29183.

Even if a portable application is used as a directory, it's better for "integration" if it's setup as a ".AppImage" AppDir, since the ".desktop" file in it's root, has all the "integration" information in 1 easy location.

[gyrog]

Back in the day, before "dyanmic libraries" every application was "portable", since only complete static loading was available.
On pc's they were called ".com" files.

[fredx181]

Hi All,

Following up on my post about "cr-appimage" Here I did some more experimenting, trying to improve, here's second version, cr-appimage2-firefox.tar.gz attached:

cr-appimage2-firefox.tar.gz

(153.58 KiB) Downloaded 112 times

Changes:
- Method is more like a "standard" setup of an appimage (as @gyrog suggested, I agree it's better way), i.e. creating a .desktop file inside "$APPDIR" and AppRun reads the "Exec=..." line ($EXEC variable) from it to execute script or binary.
- Running the appimage "installs" a . desktop launcher (pointing to the appimage) in ~/.local/share/applications, so it should be added to the menu (category 'Other' ?).

When copying the appimage to another location and run it from there, then the "Exec=..." path in the .desktop launcher will be updated.
Now... is that nice or... is that nice ?!
To have the .desktop launcher created at the same level as the appimage, edit in the cr-appimage2 script to:

Code: Select all

# set .desktop file location for to launch the appimage, comment/uncomment one of the two below ( DESKTOPLOCATION=)
# add to .local/share/applications, so should be added to menu
#DESKTOPLOCATION='$HOME/.local/share/applications/'${NAME}'.desktop'
# .desktop launcher at the same level as the appimage
DESKTOPLOCATION='$(dirname $APPIMAGE)/'${NAME}'.desktop'

After running ./cr-appimage2 from terminal standing in the directory that you want the appimage created from, the appimage will be created, but also this directory can be used as a "Rox-app", or run ./AppRun from this directory and it will launch the program, same as when running the appimage.

To manually edit variables and script "runapp" see section:
############ Set Variables and create runapp script ############ in the cr-appimage2 script.

I've been thinking about a "generic" way to modify existing appimages, so that it creates a .desktop launcher, but so far I think it will be very difficult/tricky, if even possible.

Appimage "Firefox-Portable64" made this way (make it executable before running):
https://drive.google.com/uc?export=down ... _ldwxdeC2s

EDIT: Shared 32-bit and 64-bit firefox appimages here: viewtopic.php?p=29854#p29854
EDIT2: Appimages created similar way, Google-Chrome and Opera:
viewtopic.php?p=29855#p29855
viewtopic.php?p=29856#p29856

Fred