Discussion, talk and tips
https://forum.puppylinux.com/
On my PC with S15Pup64, using PPM, installing gimp does not stop after installation. Keeps going..., after waiting for 35min, I manually stopped it. There was no error, and was actually able to use the gimp. It does install but PPM does not seem to stop but keeps downloading ??
@ gychang: S15Pup (64bit) will happily use either MikeWalsh's gimp-portable or a Gimp AppImages. The AppImage I have is version 2.10.1 I obtained a couple years ago. As all my 64-bit Puppys can use it I haven't looked for a newer version. It's help>about dialog says copywrite thru 2018. Mike's is version 2.10.25.
That both of the above could be used with any Puppy was one of the reasons I stopped installing gimp. The other being like your experience: the need of an 'install' to download many libraries, the time that takes and the potential for transmission problems.
Now that I realize its been a while since I've looked for the current version I did a search. You can obtain an AppImage packaged in April here, https://apprepo.de/appimage/gimp. The original publishers Gimp seem now only to be packaging it as a flatpak. 
The latest stable version is 2.10.32. I wouldn't expect it to contain drastic changes.
Despite MikeWalsh's assurance, https://www.forum.puppylinux.com/viewto ... 169#p75169 and following his recipe, I could not get gthumb to recognize portable-gimp, even after I realized that the full name 'gimp-portable' had to be typed into the default chooser's box. Maybe it's just me. It's becoming increasingly evident that inanimate things don't like me. 
You can use the pet I provided on that thread to create a menu entry for an AppImage. Just edit the bash script in /root/my-applications/bin to read:
#!/bin/sh
/PATH-TO-APPIMAGE/gimp.AppImage
Appimages can be renamed to anything. The absence of "exec" and "$@" from the above line is NOT a mistake.
mikeslr wrote: ↑Mon Dec 12, 2022 3:01 pm@ gychang: S15Pup (64bit) will happily use either MikeWalsh's gimp-portable or a Gimp AppImages. The AppImage I have is version 2.10.1 I obtained a couple years ago. As all my 64-bit Puppys can use it I haven't looked for a newer version. It's help>about dialog says copywrite thru 2018. Mike's is version 2.10.25.
That both of the above could be used with any Puppy was one of the reasons I stopped installing gimp. The other being like your experience: the need of an 'install' to download many libraries, the time that takes and the potential for transmission problems.
Now that I realize its been a while since I've looked for the current version I did a search. You can obtain an AppImage packaged in April here, https://apprepo.de/appimage/gimp.
You can use the pet I provided on that thread to create a menu entry for an AppImage. Just edit the bash script in /root/my-applications/bin to read:
#!/bin/sh
/PATH-TO-APPIMAGE/gimp.AppImage
Appimages can be renamed to anything. The absence of "exec" and "$@" from the above line is NOT a mistake.
thanks @mikeslr I appreciate it.
The last iteration of S15Pup64 did NOT provide all of the Right-Click options I discussed on this thread, https://www.forum.puppylinux.com/viewto ... 513#p69513. I think that having them built into Slackos is perhaps more important than having them built into 'debian/Ubuntus'.
The repositories of debian and Ubuntu can provide many more applications than those of Slackware. Slackware's orientation is to provide a basic operating system: if you want more, compile your own applications from scratch. debian --and especially Ubuntu-- strive to compete with Microsoft in providing applications with 'Bells & Whistles' easily obtainable. Independent publishers of applications don't test their utility under Slackware. And Puppy doesn't even provide or have available in its repositories the 'frame-work' applications (such as Qt5 and python) upon which most complex applications depend.
The ability to 'flesh out' a Slacko requires tools (sometimes having to extract a package), to examine what is missing or doesn't work using LIstDD and/or 'run in terminal' and ultimately repackage using 'create a pet' or dir2sfs.
Agreed on rightclick options. I'm lost without them.
Just a note: In @peebees' LXDE ydrvs and LxPups, there has been for some time a good option to add rightclicks under Menu>Desktop>Change appearance>Options. Being of the LXDE/PcManFM persuasion, I run that ydrv in both the current S15 and Void 64b pups. Once installed, the basic set of rightclicks resides in /usr/share/applications/lxrightclicks and are pretty easy to customize.
Thanks, Marv, for mentioning capabilities when LXDE ydrvs is employed. I'll have to look into that. Maybe like everyone else 'I hate change', especially after struggling to come to grips with the world as it is.
A long time ago I argued that rox-jwm should be replaced. Then I got used to rox, learned at least some of its finer points, and more recently have publicly expressed wondering why other file-managers aren't as efficient. If I'm fickle, I'm slow about it. 
Maybe it's time for me to spice up my life. 
I love LXDE for business/office uses and as my daily driver. I especially like the way the desktop can be utilized as an always visible storage folder for interim files which dont need to be deleted using shutdown/no-save . But it does run a bit slower than JWM IMHO.
For more technical work (eg photo/video/sound rendering) JWM is blisteringly fast and has many more menu/right-click options than I can utilize. It does take a while to get used to it, but there are some times it's invaluable.
In EasyOS & Ub-based Puppy I've used a Debian package for xkbset to use for enabling sticky keys, but I don't know what to use for S15Pup 64.
I see the it has an accessibility toolkit installed by default, but that isn't what I'm looking for.
Packages, such as txz, are created because an operating system's package manager knows what to do with that format of packaging. The content of the package is frequently identical from one operating system to another. Any Puppy can 'install' any package regardless of its format. However sometimes the files are different --compiling differences-- and there's a fundamental structural difference between 64-bit packages created for Slackware and those created for debian/ubuntu. Slackware locates 64-libraries in folders named /lib64 while debian/ubuntu locates them in folders named x86_64-linux-gnu. [ 
Dumb]. What you can sometime do is extract a package, rename the folder(s)* and repackage it with 'Create a pet package'.
But back-up your SaveFile/Folder first; and/or run under PupMode13 and test the result (and its possible impact on other applications) before committing to a Save.
In short, you may be able to use the package you already have, But precede with caution.
---
* debian/Ubuntu now also insists that Users can NOT create folders except under /usr. So if a top-level /lib64 folder appears, its content has to be moved to be under /usr, /usr/local, or [Puppy being Puppy and unique], /root/my-applications/lib.
I share motion and guvcview appdirs created by fred's create-portable and working in my S15Pup install which became my main puppy. May work in other puppies.
motion:
https://drive.google.com/file/d/1LsD1GT ... sp=sharing
guvcview:
The black retrovol icons were not visible on the dark blue tray background so I change them to white in a .pet. Posted here in Additional Software/Desktop .
OscarTalks wrote: ↑Fri Dec 02, 2022 2:01 amVLC now version 3.0.18
Compiled from source in S15Pup and packaged as .pet
Uploaded for testing
http://smokey01.com/OscarTalks/vlc-3.0. ... 4-s15p.pet (64bit)
http://smokey01.com/OscarTalks/vlc-3.0.18-i686-s15p.pet (32bit)NOTE:- The VLC website has a security bulletin saying that some vulnerabilities in earlier versions are fixed in 3.0.18
Users should decide how relevant such things are, but anyway, with S15Pup now released and a Distrowatch candidate I think it is nice to have this version available for it.
See here for the information:-
http://www.videolan.org/security/sb-vlc3018.html
I just installed your VLC pet for fossa64, THANKS! I had been using an appimage.
Need the /var/packages directory of this Puppy please (if there is one). Attach it here please. Thanks.
@amethyst - hopefully this & next post are what you want (total size was over 500k).
s15pup64-2212+1 /var/packages attached (minus builtin)
s15pup64-2212+1-/var/packages/builtin attached
Thanks so the same as traditional Puppys. I gather user-installed-packages will be in /var/packages (both the file lists and package lists) and it uses the standard Puppy Package Manager? How many additional drives are available and order of preference (in aufs)?
Yes & yes.
Traditional adrv, fdrv, ydrv, zdrv and usual order of preference as per viewtopic.php?t=5818
peebee wrote: ↑Tue Jan 03, 2023 1:23 pmTraditional adrv, fdrv, ydrv, zdrv and usual order of preference as per viewtopic.php?t=5818
@peebee that post is incorrect since https://github.com/puppylinux-woof-CE/w ... 0a22ce2f13. The stacking order of the SFSs is the same, and so is the lookup algorithm. However, SFSs are no longer copied to RAM in the order of loading. Instead, if only some SFSs fit in RAM while leaving enough RAM for running applications, SFSs are prioritized and only the more frequently accessed SFSs are copied to RAM. (Not based on any collection of statistics over time, but using a predefined order).
For example, fdrv is the first SFS mounted after the main SFS, before adrv and ydrv. Before this change, it was also the second SFS to be copied to RAM. Now it's copied to RAM only after the main SFS, adrv, ydrv [...], only if these higher-priority SFSs are already in RAM and only if remaining RAM is sufficient for fdrv as well. adrv and ydrv contain applications which will start faster if they're copied to RAM, while fdrv is used only when newly connected hardware is detected: the user won't feel any difference between fdrv in RAM rather than on disk and it's a waste of RAM to copy it if RAM is low.
dimkr wrote: ↑Tue Jan 03, 2023 2:02 pmpeebee wrote: ↑Tue Jan 03, 2023 1:23 pmTraditional adrv, fdrv, ydrv, zdrv and usual order of preference as per viewtopic.php?t=5818
@peebee that post is incorrect since https://github.com/puppylinux-woof-CE/w ... 0a22ce2f13. The stacking order of the SFSs is the same, and so is the lookup algorithm. However, SFSs are no longer copied to RAM in the order of loading. Instead, if only some SFSs fit in RAM while leaving enough RAM for running applications, SFSs are prioritized and only the more frequently accessed SFSs are copied to RAM. (Not based on any collection of statistics over time, but using a predefined order).
For example, fdrv is the first SFS mounted after the main SFS, before adrv and ydrv. Before this change, it was also the second SFS to be copied to RAM. Now it's copied to RAM only after the main SFS, adrv, ydrv [...], only if these higher-priority SFSs are already in RAM and only if remaining RAM is sufficient for fdrv as well. adrv and ydrv contain applications which will start faster if they're copied to RAM, while fdrv is used only when newly connected hardware is detected: the user won't feel any difference between fdrv in RAM rather than on disk and it's a waste of RAM to copy it if RAM is low.
Why did this order change, it really is getting very confusing even for old time users? adrv, ydrv, bdrv, base, fdrv, zdrv (will be the order most familiar to users). All additional drives to have preference to the base, fdrv and zdrv like we have had for years. I also don't like the idea that loading now seems random with whatever is likened to be grabbed first. Can this order be changed to the way we are used to? You either have enough RAM or not at bootup for loading/copying into RAM, init shouldn't decide for you which should be grapped first now in my view. It could lead to a total mess up depending how you operate and what the contents of your other additional drives are. BTW, I don't experience much difference in performance when the SFS's are loaded/copied to RAM or not copied (nocopy). The essential stuff are loaded into RAM at bootup anyway and of course using pfix=nocopy your booting should be much faster (especially with a slow machine). Also - in both cases the sfs's are loaded but the default is/was that the sfs's will also be copied to RAM if you have enough RAM, however in both cases the contents will still have to be extracted to be used. Extracting it from the sfs copied to RAM is supposed to be faster but in my experience not really all that noticeable.
Again, the loading order is the same. The only difference is the choice of SFSs copied to RAM when pfix=copy is not specified. If RAM is too low for all SFSs to fit in RAM, it's not wasted on things like fdrv, and spent on adrv and ydrv instead (if possible). For all users except those trying to run a big Puppy without enough RAM for all of its SFS to fit in RAM, this doesn't change anything.
The concern is the order of preference in aufs and what users have been used to for over the years . We general only had the adrv and ydrv besides the fdrv and zdrv. The fdrv never had preference to the ydrv and adrv as far a I know. Now we have a bdrv as well , personally I have 26 additional drives envoked. My issue is with what people are used to, therefor I'm concern when bringing in a new additional drive like a bdrv, when it has preference in order to the ydrv. Bring it in but keep the original order of preference, in this case to have the ydrv preference in order to the bdrv, that's all, not too difficult to keep it that way.
Apart from a bdrv that has been brought in and someone deciding that that should have preference to the ydrv now which have been with us for a long time and have been used for different functions (in many cases using it to save system configurations) where a save file /folder is not in use.
bdrv was introduced ~9 months ago is not present by default in any Puppy except dpup, so it's 100% backward compatible for old timers and ydrv users. As long as you don't use bdrv for purposes other than its intended purpose, you should be fine.
It's also present in the new FossaPup attempt. Who decided on the bdrv's "intended" purpose. A random thought plucked out of the sky?
OscarTalks wrote: ↑Wed Nov 16, 2022 12:41 pm<cut>
http://smokey01.com/OscarTalks/psip-1.4 ... 4-s15p.pet (64bit)
http://smokey01.com/OscarTalks/psip-1.42-i686-s15p.pet (32bit)
I found that Psip in 64 bit does not regularly connect to Diamondcard (Ex Ekiga Call Out to telephone to PSTN numbers) but it properly works with an IPTEL account and virtual accounts. Maybe I was someway deactivated the service with Diamondcard even though I was able to connect in random cases.
watchdog wrote: ↑Sat Jan 07, 2023 10:59 amI found that Psip in 64 bit does not regularly connect to Diamondcard (Ex Ekiga Call Out to telephone to PSTN numbers) but it properly works with an IPTEL account and virtual accounts. Maybe I was someway deactivated the service with Diamondcard even though I was able to connect in random cases.
Hello watchdog,
Are you saying that Diamondcard in S15Pup PSIP works some times but not other times, or never works in S15Pup PSIP but does work in other PSIP versions or in other Pups? I am a little unclear about exactly what you mean.
Unfortunately I can not test Diamondcard specifically as I do not have an account with them. I am not sure of the status of Diamondcard as a provider but I notice that their website has the date 2020 and not 2023 or 2022. Perhaps their service is not fully maintained? I believe they were "partners" of Ekiga, but Ekiga seems to be abandoned or certainly not developed much at all for a few years now.
With SIP service providers it is sometimes a case of trying them out and if one does not work then try a different one. They do vary in terms of reliability and performance. I still think PSIP is a useful program which works very well in the majority of cases including the PSTN Call-Out services which I use myself. If you are able to find some sort of error message which gives clues to any problem I can try to improve things. In terminal I can see that TLS transport is working, but I have to include an older version of openssl libraries in the package in order to achieve that. Maybe I will PM "jamesbond" and ask him if it would be possible to patch the PSIP source so it will link against the newer openssl-1.1.1 because for me it seems to refuse to do that at present.
@OscarTalks I'm happy to report that DiamondCard service now, from some days, works in a regularly mode with PyppyPhone. NAT traversal only requires to set the Public Ip in Setup. I was in some ways reactivated in service after my attempts to connect. PuppyPhone is still a good software as it is maintained by @jamesbond. I also use the Iptel account. There are also Android apps to use Sip protocol and telephone from PC to smartphones. I only tested in S15Pup64.