Using AppImages in Puppy...

[ahoppin]

> Like any Linux program.
> They require specific dependency files/programs to be in the Linux OPS.

Now wait, you mean these aren't static builds with all the dependencies compiled in? That seems all wrong to me.

IMO you should be able to put them on a thumb drive, plug the drive into any system, and run them instantly. They should require nothing but a bare Linux system to start, and leave nothing behind (not even config files or cache entries) when they exit.

Or am I misreading / misunderstanding this? I don't think I've heard the term "appimages" before, so maybe I don't get it.

[mikeslr]

Hi ahoppin,

The first public release of Linux was in 1991. That was 26 years ago. It's main significance in the grand scheme of things is that it was freely modifiable by anyone. And it was. Figure you start small, one modified version in 1992, with a modification of the 2 in 1993, 4 modifications in 1994 and so on. Trying to remember something from my 12th grade advanced math class --to pass it I needed a tutor, which led me to decide I wasn't really cut out for a career in physics-- the formula, I think, is 1 times 2 to the 26th power minus 1: x= 1 x (2pwr26*)-1**. At any rate, a lot. Distrowatch now reports on 285 published distros. At its height it reported on 323. Each of those distros may be available for different architectures, with different kernels and different window-managers resulting in several different "base" systems. A big lot.

For an application to run, the libraries --foundation files-- it requires either have to be present within the build of the application [a static build] or by the application accessing the libraries otherwise found on the system it is running under [shared/dynamic build]. An AppImage is a static build. But to have a static build which will run under every Linux OS -- well, picture the great wall of China and the time it took to build it. [Possible work-arounds: something like Wine, an application layer which can run under any distro and into which you could install applications. Or Java or Qt frameworks, but for these the application developer has to be able to program under them. Which is why many of us still employ Wine]***.

There is a serviceable work-around, not complete but serviceable. If clicking an AppImage doesn't result in a fully functional application, copy the AppImage giving it a simpler name, e.g. myapp. [Saves having to later type over a dozen alphanumerics]. Open a terminal to myapp's location and type "ldd myapp" -- without the quotes; or better still "ldd myapp > /root/myapp.txt". This will generate a text file in /root named myapp whose contents will show what libraries are present and which are absent. Install into your system the previously absent libraries. In many cases the AppImage will now function. Not as good as having the entire application outside of your operating system, but as libraries take up little space and are often few in number, better than having to install the entire application into your system; especially as the creator of the AppImage has done most of the hard work. Kind of like a modular home. You still have to lay the foundation and hook up the water and electricity.

mikesLr

* Forum software can't produce superscripts. 2 to the 26th power is 2 x 2 x 2... there being 26 2s in the string.

** In practice, there's a limiting factor. You run out of humans.

*** And see this thread: http://murga-linux.com/puppy/viewtopic. ... 063#963063

[Mike Walsh]

Morning, all.

@ ahoppin:-

As I understand it, these AppImages are using pretty much a self-contained set of libs, etc. They do, however, seem to generate cache and config entries which they leave behind. I can't speak for other Linux distros (hell, I came to Puppy to get away from all the crap associated with most of the others!!), but there's a very simple way to make the AppImage self-contained (at least, where Pup's concerned.)

Very much along the lines of Davids45's 'remote applications' (achieved through liberal use of Pup's powerful sym-linking function), you would simply move the AppImage's .cache & .config files from /root into the AppImages's own directory, then sym-link them back to where you've just moved them from. That way, when you disconnect your USB drive with your AppImages on it, you are indeed moving the .cache & .config files with it. It'll still work as intended with any other Linux distro, and as far as Pup's concerned, all that's left behind is a pair of inactive sym-link 'pointers'.....which occupy no space at all.

Assuming your AppImage remains in exactly the same location on your USB drive, every time you plug it in and re-start it, the sym-links should re-activate. (As long as the USB drive mounts under the same mount-point, that is; otherwise, you'll have to re-create the links.)

That's just my 'take' on the matter, but I suspect the other Mike will agree with me on this one. I'm already using a couple of these on a regular basis; a single instance of the AppImage on an auto-mounted remote 'data' partition, started via MenuEntries in each Pup which I've manufactured for the purpose (it was Mike who put me onto the possibility of creating these in the first place, a couple of years ago).....workable, since these things are designed to run from anywhere (they are, of course, intended to be truly 'portable' from the the word go, and invariably start from an executable binary).


Mike.

[Mike Walsh]

Afternoon, all.

Further information following on from using the Wire (Skype-type) AppImage for a few weeks:-

I've been using Wire across the kennels for a wee while now. Currently a total of 14 Pups; 10 on the big ol' Compaq desktop, and 4 on the old Dell lappie. On each machine, I'm running just a single instance of each architecture of Wire; one each of 32- and 64-bit on the Compaq, a single 32-bit instance on the old Dell (P4-based). In every Pup, since this is an executable, self-contained binary, and will run from anywhere in the system, I've constructed Menu entries for starting it......and this works very well.

In practice the only restriction I've come across with it is the number of 'registered' instances that you can have 'logged-in'. WireGmBH, the Swiss developers of this program, arbitrarily limit you to 7 instances 'on the go' at any one time..!

Ordinarily, of course, this limit wouldn't in practice be reached by most people. It's only Linux nuts like us who run multiple OSs who would get near it. Wire digitally 'fingerprints' every OS 'install'; even the same remote AppImage will generate a different fingerprint depending on which Pup you run it in.....no doubt using your Pup's hostname to differentiate between them.

If you approach your 7-login 'limit, you're offered the chance to input your password and delete an existing login, thus enabling you to login afresh on a new machine. It works well, and there's no limit to the number of times you can chop and change like this.

The only other thing I find a bit niggling is that on a fresh login, Wire won't show your chat history 'for security reasons'. Existing logins, this shows up as expected when you fire it up.

On the whole, I'm quite impressed with it, so far..!!


Mike.

[Mike Walsh]

Evening, all.

Further information for you:-

I've just been trying out Krita; a professional painting/sketching program, capable of doing comic layouts, etc. It's laid out somewhere along the lines of a cross between Photoshop and the GIMP.

I didn't obtain this one from the same location as the others, further back in the thread; this came from the Krita website, as a directly-packaged, AppImage download. Same principle as the others, though; simply make it executable, and run it from anywhere you like.

Although 64-bit only, it runs perfectly in Tahr64 6.0.5., and starts up without any fuss at all. Slacko 64 6.3.0, on the other hand, doesn't want to play ball; 'libGL.so.1' in /usr/lib64 appears to be involved, with a 'symbol lookup error'..?? (I've never understood these, I'll own...)

Thoroughly recommended, if you take your graphics seriously (as I do). This'll give me plenty of opportunity to try out my newest purchase, a 'pen mouse'.....

Enjoy.


Mike.

[Mike Walsh]

Hi Mike & All,

I was curious to see if the Chromium AppImage would work. It failed to start, indicating either to run it as a normal user or specify an alternative "user-data-dir" for storage. As the AppImage is a "binary" we can't modify, I wonder if it were possible to start it via a "wrapper"? and, if so exactly how? Coding is not my strong suite.

There may be others. VLC comes to mind. Maybe. I remember some discussion from a "DebianDog" thread about VLC.

mikesLr

Hiya, Mike.

I thought I'd re-visit this one. I've been mulling over what you said about starting it via a 'wrapper-script', and I think I've come up with a solution.

Rather than trying out the Chromium AppImage, what I've done is to try out the 'Iridium' one; it's another Chromium clone anyways, so the principle's gonna be the same. I'll be trying out Chromium itself later on, but I just thought I'd update you on what I've got so far.

1) I downloaded the Iridium AppImage from the site in post #1.

2) I created a new directory at /opt/iridium.

3) Into this, I've moved the AppImage itself.....which I've renamed. (You can do this with 'em.) I then made it executable, by ticking the 'Exec' boxes in 'Properties, then refreshing.

4) I've used PhilB's 'bbe' script, which is just another way of achieving the same effect as Iguleder's libpuppygc.so; it 'fools' the browser into thinking it's running as a normal user, that's all.

Phil's script:

Code: Select all

#!/bin/sh 
if [ -f /usr/bin/bbe ];then 
if [ -f "$@"  ];then 
bbe -e 's/geteuid/getppid/' "$@" > /tmp/antiroot-temp1 
mv -f /tmp/antiroot-temp1  "$@" 
chmod 755 "$@" 
fi 
fi

.....which is further into Iggy's thread:-

http://www.murga-linux.com/puppy/viewtopic.php?t=72667

Oscar's been using this with great effect on the SlimJet, Iron and Vivaldi 32-bit builds; you simply 'drop' whatever you want to change the 'root' properties of onto the script. Since an AppImage is one giant 'binary', I 'dropped' the entire thing onto the script!

5) Borrowing from peebee, Oscar, and using some of my own experience, I've created a wrapper script to launch it, and add PepperFlash functionality, as follows:-

Code: Select all

#!/bin/sh
#
#Wrapper script for Iridium AppImage
#
exec -a "$0" /opt/iridium/Iridium-46.AppImage --user-data-dir=/root/.config/iridium --ppapi-flash-path=/opt/iridium/PepperFlash/libpepflashplayer.so --ppapi-flash-version=2
6.0.0.151 --disk-cache-size=10000000 --media-cache-size=10000000 --allow-outdated-plugins --disable-infobars "$@"

6) The directory contents currently look like this:-





7) Click on the wrapper script, and after a suitable delay while it 'sets-up' the .cache and .config files in /root,.....it launches!

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

One peculiarity I've noticed with Iridium is that it won't save settings between sessions....but this could be because, as with SlimJet & Iron, where they concentrate on the 'privacy' side of things, Iridium appears to take this to extremes. It's the one Chromium clone I've found that's closest in concept to the Tor browser; anonymity takes precedence. It does remember bookmarks, and will save extensions you add from the Chrome Web Store, but you'd need to import bookmarks as an HTML file from another Chromium browser, because Iridium won't let you sign in to a Google a/c!

As with FireFox and the Mozilla-browsers, you then need to organise these manually. But, there's your answer. These browser AppImages can be started via a wrapper......and a wee bit of good old Puppy ingenuity!

It may even work for VLC; that was the other one we found moaned about running as root, wasn't it? I'll have a look into that, too, when I find time; I've proved the principle works.....and that was the object of the excercise!


Mike.

[Mike Walsh]

Well, I've got the Chromium 55 AppImage up-and-running, too. Posting from it now.

This one's behaving much the same as Iridium, though for different reasons. It's identical to the Windows portable Chromium, and has been compiled without the API keys.....so you can't sign in to a Google a/c even if you wanted to!

As with the other, it's easy enough to import your bookmarks as an HTML file, and then organise them. Also, to reinstall your extensions manually from the Web Store.

I'm thinking this could be truly made into a portable. There's no reason that /root/.cache & /root/.config folders have to be created in those locations. We only tend to set those for a 'user-data-dir' in the wrapper script because it's 'traditional'.

I can't see why you couldn't create .cache & .config folders inside your self-contained browser folder.....then specify that as the location for the 'user-data-dir'. I've come to realise that once the .config folder has been created, the browser then sets up the .cache folder on the same level.

The browser is only interested in a location for the .config folder that isn't '/root'.....and doesn't have 'root' permissions. It couldn't care less what you actually call it..!

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

VLC, however, is an entirely different ball-game.....

On first attempt to launch from the terminal, it does indeed (as bigpup found) insist it can't run as root. It creates a binary in /usr/bin called 'vlc-wrapper'; it then (get this!!) insists that if you want to try it out, that you create a hidden directory in /tmp; that you create /usr inside of it, /bin inside of that, place the 'vlc-wrapper' binary inside of that.....and, as if that wasn't enough, it then insists the binary must be isolated behind an SUID sandbox before you're permitted to even think about trying it out.....

Using the 'bbe' script has absolutely zero effect.

I don't know who they're trying to kid. What the hell does a media player need that kind of isolation for?


Mike.

[Mike Walsh]

Evening, all.

A couple or three more AppImages that will work with 64-bit Pups, without any messing about.

Scribus v1.5.2:- https://www.linux-appimages.org/p/1168358/
You'll find the AppImage link under the 'Files' tab.

VidCutter v4.0.0: this is a video 'clip cutter' utility, which works very well indeed. It's got an extremely professional-looking, modern GUI, which is beautifully laid out (even smarter with the optional 'Dark' theme).....and was last updated on the 11th of this month:- https://www.linux-appimages.org/p/1180755/
Again, look under the 'Files' tab for the link.

Well worth a look.

And finally, a utilty for analyzing data obtained from OMRON blood pressure monitors. Because this is a subject close to me personally, I've turned this one into an SFS for anyone else who may find it useful:-

http://www.murga-linux.com/puppy/viewto ... 336#965336


Mike.

[don570]

There are some 64 bit appimages available for Mypaint

To download ...

Go to build page

Click on build number to find the script to build appimage.
At the end of the script there is download link such as
https://transfer.sh/JHudR/MyPaint-1.3.0 ... 4.AppImage

Warning! They are buggy in fatdog linux.
Worked in Quirky xerus
_____________________________________________________

[Mike Walsh]

Thanks for that, Don.

I wasn't aware we (the 'great unwashed'! ) could build AppImages ourselves. I guess the means must be available, like. It opens up all kinds of possibilities, that does.....!!


Mike.

[don570]

Only the most recent build seems available for download.
Build #952 at top of list is available.

Mypaint 1.3.0 integrates well with GIMP because of clipboard transfer
_________________________________________________________

[mikeslr]

Hi Mike and All,

Edit: Should have waited before posting. Initiating 64-bit version under XenialPup64 seemed to go well. But trying to start the application (by clicking, then via terminal) ends up with a segfault:

"/tmp/.mount_PvLGY3/AppRun: line 40: 11429 Segmentation fault digikam.wrapper $@"

Under Xenialpup, the 32-bit version also segfaults.


Thanks for continuing to explore the potential of AppImages which brought them back to my attention.

I may be mistaken, but https://www.linux-appimages.org/browse/ seems to be another source, or consolidator. The website's left-pane is a listing of clickable categories which makes it much easier to locate applications of interest. Clicking on Graphics revealed an AppImage of digikam, a photo-management application with a host of features. https://www.digikam.org/about/features/. Among those feature is its ability to export your photos to many online venues which host albums.

I first learned about digikam when John Biles included it in Teenpup, but took a greater interest as Picasa became increasingly unworkable. digikam, however, was developed for the KDE environment so trying to adapt it to Puppy seemed a stretch. An AppImage, however, might be just the ticket.

Following linux-appimages.org's links to digikam revealed both 64 and 32 bit versions. https://www.linux-appimages.org/p/1168433/.

Nice of them to also provide links to 32-bit versions of applications.

mikesLr

[Mike Walsh]

Hiya, Mike.

Did you by any chance give my suggestion of dropping the AppImage binary on PhilB's 'bbe' script before you gave it a whirl? It will sort out root permissions, if nothing else.

It doesn't always do the trick, as I found out. VLC being a case in point.....

(And, as you've doubtless noticed, they do take a wee while to start. It's because they're unpacking, and setting-up shop in /tmp, which is where they 'live' for the duration...)


Mike.

[mikeslr]

Hi Mike,

I hadn't thought of 'bbe-ing' it before trying to run digikam.appimage. Tell me if I've got this right:

1. create a bash-script; Right-Click Empty Space >New>script. Named it bbe.
2. Into it copy contents of script from here: http://www.murga-linux.com/puppy/viewto ... 856#943856. Delete duplication of #!/bin/sh.
3. Make it executable.
4. Drop the application (in this case digikam.appimage) onto the script.

I did that above. Nothing seemed to happen. But then with Quad-core and 8 Gbs of RAM I might not have noticed.

digikam still ran thru its setup and then segfaulted.

mikesLr

[Mike Walsh]

Hallo, Mike.

Yes, you've got that right. And you say it hasn't helped? Hmmm.....can't say I'm surprised.

I've been doing a wee bit of research this afternoon, trying to understand exactly what segmentation faults are, and the best ways to deal with 'em....

Few articles here that detail some of the causes:-

http://smallbusiness.chron.com/segmenta ... 27699.html

https://en.wikipedia.org/wiki/Segmentation_fault

https://stackoverflow.com/questions/320 ... t-on-linux

Seems it's usually to do with trying to access memory (in programs written in 'C' & 'C++') where the memory hasn't been properly allocated...(???)

(Layman's translation, poorly written.)

Beyond that, I'm at a bit of a loss; I don't really know where to go from there. One suggestion was to make use of the GNUtils 'debugger' (which apparently is a stupefyingly long process, even for small programs).

We're only attempting to use 'em, not re-write 'em..... And as I understand it, Digikam is a KDE app, anyway... 'Nuff said..!


Mike.

[don570]

The latest appimage for mypaint...

https://transfer.sh/lekBy/MyPaint-1.3.0 ... 4.AppImage
________________________________________

The method for getting this download site is...

go to https://travis-ci.org/mypaint/mypaint
then look at bottom of script (near bottom of page)
_____________________________________________

[Mike Walsh]

Thanks for that, Don.

All information pertaining to use of AppImages gratefully received.....

Cheers.


Mike.

[don570]

There is an appimage for gimp 2.9.5 that has mypaint brushes included
Available HERE


However I find the brushes slow so I prefer mypaint as a standing app.
Latest version of mypaint has perspective tool.
______________________________________________________________

[LazY Puppy]

Hi.

Yesterday evening accidentially I found a Kdenlive 17.04 AppImage:

It needs QT5 to be installed, otherwise it complains about a missing qt xcf plugin and won't start.

https://files.kde.org/kdenlive/release/ ... mirrorlist

In tahr64 I got a segmentation fault and it crashed after trying to import/drag'n'drop a mp4 video into Kdenlive.

Probably it may work in Xenial64?

Meanwhile there's also a Kdenlive version for Windows available, though I can't test, since I do not own a 64bit Windows version.

[Mike Walsh]

Morning, all.

I've made another discovery with regard to WIRE, the VOIP/chat AppImage.

Back on page 3 of this thread, I mentioned about WIRE creating a fresh 'instance' of itself each time, when running it on multiple Puppies, even using the same 'common' AppImage in each Pup.

http://www.murga-linux.com/puppy/viewto ... 425#953425

If you approach your 7-login 'limit, you're offered the chance to input your password and delete an existing login, thus enabling you to login afresh on a new machine. It works well, and there's no limit to the number of times you can chop and change like this.

The only other thing I find a bit niggling is that on a fresh login, Wire won't show your chat history 'for security reasons'. Existing logins, this shows up as expected when you fire it up.

As stated above, when running a common AppImage this way on multiple Pups (unlike with Skype), your chat 'history' won't be synced across every instance of WIRE, due to WIRE 'seeing' each Pup as a fresh 'install', if you like.....and WireGmBH have coded it to work like this for 'security' reasons..!

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

The essential difference here is that Skype keeps your configuration details remotely on a cloud server somewhere, linked into your a/c details.....whereas WIRE keeps that same information locally, as a set of configuration files, in a folder named 'Wire' in /root/.config.

What this means is as follows:-

a) You're having a chat conversation with somebody in Puppy 'A'.
b) For whatever reason, you decide to switch to Puppy 'B', but wish to continue the conversation. You open WIRE, but.....no chat 'history' (for security reasons.) So, you have to remember what you were chatting about.....

This struck me as absolutely DAFT.....although I can see the 'logic' behind it, since WIRE is primarily intended for smartphones. And most people only have one smartphone, which they keep with them at all times. Although the Linux desktop client is freely available (and works very well), it's still set up to work like the phone app...and those 'security reasons' are obviously in effect in case your phone gets stolen, and/or falls into the wrong hands.

There IS an easy way round this.

SOLUTION

You keep a 'common' .config folder in a remote location, separate from all your Pups (if that location is set to auto-mount at boot, all the better).....and you simply sym-link it into your /root/.config directory in each Pup, before firing-up WIRE.

Result? WIRE now 'sees' each Pup's instance of itself as the same 'install'.....and your chat history is preserved across your kennels.

Hope that helps anyone who's been trying to suss this one out..!


Mike.