(old)Puppy Linux Discussion Forum

Hi,
I just tried out an appimage for Synfig 1.2 using precise 5.7.1 - it didn't work.

When I tried from the console (urxvt) there were so many error messages I couldn't read the first ones because they disappeared as the error messages scrolled upwards!

Eventually with the help of screeny I managed to see that the first error message was that lbconfig could not be found

Could that first problem lead to all the rest? Why can't I run lbconfig but only get told 'command not found'?

Otherwise I tried subsurface appimage that I believe was offered on that main page for appimage (not the one that has all the packages available) - and that worked fine though I have no need for the program as I don't dive

If something is packaged as an appimage only is it then going to be impossible to get it to work on puppy if it won't work with the appimage because it being an image sort of makes it not able to be changed at all, right? I suppose then unless you can get ahold of the binaries you can't really use the program if that's the only way it's packaged? Is that right?

Evening, all. An 'update' for you...

For anybody who might be looking to break away from Skype's stranglehold, there's a new one you might be interested in. I know there's a few others, like Ekiga, Linphone, et al.....but, like Skype, this one not only does VOIP stuff but also the usual messaging chat as well.

It's called Wire. It's in the AppImage listings mentioned at the start of this thread, but, as with everything on that site, it's 64-bit only. However, there is a 32-bit AppImage available. If you go to Wire's own 'get the app' page:-

https://wire.com/en/download/

.....and scroll down, the Linux d/loads are at the bottom right of the page. If you click on the dropdown, underneath where it says 'Get Source Code' below the penguin, you'll see a listing for 'AppImage 32-bit'. Click on this, and it'll open your 'Downloads' dialogue box, ready to save it.

It's in the same style as the 'Telegram' instant messaging app which I've also been playing about with in recent months.....very sparse, and 'modern'-looking. It does, however, work nicely, firing up without hesitation in every Pup I've tried it in, 32- and 64-bit alike. And because it's cloud-based, as soon as you've created an account & set it all up in your first Pup, everything's 'ready-to-go' when you fire it up in subsequent Pups. Plus, it's totally cross-platform.

Astonishingly, too, it detected the webcam correctly, and not only set-up the webcam's mike by default, but also gives you the option of which mike input to use, too. Handy for me, since I prefer using a headset/mic combo if I'm Skyping.

I roped my sister into playing guinea pig earlier on today from her Win 7 lappie.....and she, too, was pleasantly surprised at how good it was.

This one's recommended.


Mike.

Marley wrote:Hi,
I just tried out an appimage for Synfig 1.2 using precise 5.7.1 - it didn't work.

I got it to work OK in Xenialpup 7.0.8.1

Got it from here:
https://www.fosshub.com/Synfig.html
Make sure you get the 32bit AppImage

Like any Linux program.
They require specific dependency files/programs to be in the Linux OPS.
Precise 5.7.1 may have them, but they are too old.
The Synfig website is not providing the info on what is needed in the Linux OPS as support.

Hi All,

There are AppImages for 32-bit Operating Systems. For example, digikam, https://download.kde.org/stable/digikam/ where the 32-bit AppImages include the identifier i386.

But they are few and far between. The best way to find one, if it exists, may be to do a web-search using the terms "appimage 32 bit NAME_OF_APPLICATION".

mikesLr

I got it to work OK in Xenialpup 7.0.8.1

Got it from here:
https://www.fosshub.com/Synfig.html
Make sure you get the 32bit AppImage

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

Precise 5.7.1 may have them, but they are too old.
The Synfig website is not providing the info on what is needed in the Linux OPS as support.

Thanks bigpup.

I have the 32bit but I might download again just in case there's a glitch in my file.

I posted the problem over on synfig too - they asked to see my error messages which were numerous beyond belief - pages and pages - old dependencies make sense. Maybe I'll ask synfig if they can be listed. Is it possible to update old dependency files if you know what they are? I've added dependencies but that's when they're totally missing -can you update them too? Or would I have to switch puppies . . . which brings me to the final quesiton -

Thanks for the heads up on Xenialpup working with the synfig appimage Does Xenialpup come in English - i've only found pictures of Xenial with icons with what I think is Japanese writing underthem.

Also, is it like other pups - can I run it from a live cd?

Oh, and last but possibly most important why does Xenialpup look like a SQUIRREL??!! What happened??!!

Thanks for the input

English Xenialpup

Get the iso from the official repository.
http://distro.ibiblio.org/puppylinux/test/xenialpup/

Also, is it like other pups - can I run it from a live cd?

It is just like any other official Puppy.

Is it possible to update old dependency files if you know what they are? I've added dependencies but that's when they're totally missing -can you update them too?

Basically replacing them with newer versions will update them.

That is basically what happens if you download a program using PPM (Puppy package manager) and it also downloads needed dependencies for the program.
Those are usually files that Puppy does not have or newer versions of files it does have.

However, overall it is better to just move to using a newer version of Puppy when newer versions of core files are needed.
Those newer versions may also need other updated core programs.

why does Xenialpup look like a SQUIRREL??!!

Ask Xenialpup developer!
I think he is loosing the Puppy them idea with that desktop background

Hi !
Fredx181 from Xenial Dog did another script for creating portable apps and Applmages .

"Already a while back I have put together an app for creating portable image : 'create-portable' 32-bit only.
Some of the code I took from "AppImageAssistant" by Simon Peter (probono), known from http://portablelinuxapps.org
Didn't share yet because I didn't take the time yet to test on different puppies (works ok for me on 32-bit DebianDog and XenialDog) (maybe I'll open new thread later in Additional Software after more testing)
So since you mentioned about portable-apps you may be interested in this.

Assumed is that you have prepared already the "app-root" directory, this can be an directory from extracted SFS, .deb or .pet file or just manually put together directory structure with inside e.g. usr/bin usr/share etc... Extracted SFS probably has the best chance to make the portable app work properly (e.g. created with apt2sfs).
The application will create 'AppRun' script in this "app-root" directory and create the portable-image.
There are 2 modes to choose from: "Chroot Mode" and "Portablelinuxapps Mode"
The Chroot Mode is the best IMO because it doesn't depend on relative paths (works pretty much the same as loading an SFS, (overlay)), but may be a bit slower (starting the app) because of more complex code.
Also there's choice (checkbox) for to create self-extracting-script instead portable-image
For more info, click on Info button "

https://dl.dropboxusercontent.com/s/wzi ... ble.tar.gz
Extract create-portable.tar.gz and run 'create-portable

Here it is also for 64-bit, appimage: "create-portable64" :
https://dl.dropboxusercontent.com/s/xxz ... e64.tar.gz
Topic discussed here:
http://www.murga-linux.com/puppy/viewto ... &start=510

Quote:
why does Xenialpup look like a SQUIRREL??!!

I'm not the developer. But, our Puppies which are woofed from the binaries of Ubuntu versions have traditionally been given a name drawn from of the Ubuntu version whose binaries were used. In this case, it was Ubuntu Xenial Xerus.

Ubuntu seems to have succumbed to the charm of our Puppies. While "xenial" is from Greek, and has to do with hospitality and the proper relationship between host and guest, Xerus is the species name of an African ground squirrel. You may be more familiar with another member of the genus to which Xerus belongs and which also lives in family colonies: The Meerkat. Oddly, the young of meerkat are called Pups. So, it isn't much of a stretch to also call the young of the Xerus "Pups".

Xenialpup: an hospitable small version of Xerus.

mikesLr

Hi !
To keep this topic alive ........find it really important .

What about " Nix " Packages .....anyone ever tried it ?
Have a look here :
https://nixos.org/nix/

https://distrowatch.com/weekly.php?issue=20170424#tips

> Try this in a terminal
>
> Code:
> su - spot
>
> then start the program from there.

You can also create a desktop icon to run it this way (assuming you're going to leave the program on your disk).

First open geany or your favorite text editor. Create a shell script in /usr/local/bin with the following contents:

#!/bin/sh
su -c /path/to/your/root-averse-program spot

Save the file. For (say) vlc you might name it something like vlc-spot.

Open your file manager (ROX or whatever you use) and navigate to /usr/local/bin. Right click on the file name and set the execute flag on permissions. Alternatively, you can open a console window and type

chmod ugo+x /usr/local/bin/vlc-spot

From the file manager, drag the file vlc-spot onto the desktop to create an icon.

Now you can start your program as non-root from that desktop icon.

If you want a nicer or more descriptive icon for it, open /usr/share/icons and click on files until you find something you like. If you don't like anything there, try the various directories under /usr/share/icons/hicolor/48x48.

When you find an icon you like, right-click on the desktop icon for your new program. Select file 'vlc-spot', then Set Icon. Drag the filename of whatever icon you like onto the blank that results. Done.

It sounds kind of complicated, but it's really not. It takes just a minute or so once you've done it a time or two.

Hope this helps.

> 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.

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

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.

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.

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.

mikeslr wrote: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:
.....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:-
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.

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.

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.

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
_____________________________________________________

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.