Moderator: Forum moderators
@xenial / @gilles :-
Erm.....I don't quite get that. I have two GMX a/cs, and both work just fine in SeaMonkey.....after the hassle of setting-up all the config stuff manually. (T-Bird does spoil you in this respect - and I definitely prefer it! - but SeaMonkey certainly gets the job done with e-mail).
Are all the server settings correct? This does take some faffing-about with if, like me, you're more used to Thunderbird....
Mike. 
Puppy "stuff" ~ MORE Puppy "stuff" ~ ....and MORE! 
_______________________________________________________
Hi @mikewalsh , you keep repeating this standard install instruction in all of your builds.
I'd love to put your apps "outside the save" onto the USB stick where I keep my Puppies and data. Problem: Like all off-the-shelf USB sticks it is FAT32 formatted (and I have no compelling reason to change that), however many of your "portables" contain symlinks, which are not supported on FAT32 formatted drives. So in cases your "portables" will not work on FAT32 drives/partitions would it be possible for you to add a remark/warning?
Morning,
"The hassle of setting-up all the config stuff manually" ????? With all others browsers I have only to click on "log in"... But with seamonkey it opens nothing...
It looks to be "why doing simple when it could be done a more complicated way?"....
@MochiMoppel :-
Hello, Mochi.
I'd love to put your apps "outside the save" onto the USB stick where I keep my Puppies and data. Problem: Like all off-the-shelf USB sticks it is FAT32 formatted (and I have no compelling reason to change that), however many of your "portables" contain symlinks, which are not supported on FAT32 formatted drives.
Mm-hm. Fred mentioned this to me about FAT32 in the early days of portable-building. Since when, I've been careful not to use sym-links in the actual builds. But then, of course, I go and spoil all that by performing what I remember you called "sym-link gymnastics" (!! 
) with the configuration files & stuff.
It's possible to keep everything in-situ with most browser builds, since the means to do so has been in the public domain for many years, and what we do only builds upon the past efforts of others. These are easy enough to do, because they possess the ability to specify the location of their profile/cache.
However, many other applications I turn into portables - I believe - must have the "destinations" for their config files 'hard-coded' into the main binaries. I've tried applying the same kind of workarounds to keep everything in-house with a number of these, yet they turn their noses up at this & still locate stuff where they want it to go. Hence why I developed the "gymnastics". (I think the workaround you discovered for the SoftMaker FreeOffice suite - that of being able to keep the config files within the app's own directory - was somewhat unique. I've not been able to find similar workarounds/instructions for other apps.)
Most apps usually look to put config stuff somewhere in the user's $HOME directory (because of the usual Linux restricted-permissions, multi-user model that is expected). They'll either put it directly in $HOME, OR $HOME/.config. Some will even use $HOME/.local/share, or any combination of these three.
---------------------------
I'm wondering, now. Would you mind if I "picked your brains".....to coin a phrase?
You've proved, time and again on the forums, that you have a fairly extensive understanding of how Bash and many Linux commands work. I don't mind admitting, mine is pretty basic by comparison.
I've been thinking about an alternate way of doing the above "gymnastics". I'm wondering if there might be any way in which a portable app could be made to think that a sub-directory - within its own directory - was the user's $HOME directory rather than needing to search the system to find it.
In other words, convince it to create its configuration directories/files within a pseudo-$HOME directory instead of looking for the "real" $HOME directory. What's your opinion? Is there a way it could be done? Is it even 'do-able'?
I appreciate this isn't what your post was about.....but it's led to this "request", since I've been thinking about this for a long while, on & off. I don't mind asking for assistance, because I certainly DON'T 'know it all'. Far from it.... 
Mike.
Puppy "stuff" ~ MORE Puppy "stuff" ~ ....and MORE!
_______________________________________________________
@gilles :-
Um; I wasn't talking about logging-in in the browser. I was specifically referring to the fact that Thunderbird sets-up all the email server-side stuff for you, whereas SeaMonkey's Mail client requires the user to enter all the server settings manually.
Perhaps I misunderstood. Ah. My mistake. You're not talking about SeaMonkey's mail client; you're talking about accessing GMX through the webmail app, aren't you?
LATER:- Huh. Seems you're right. In SeaMonkey, you cannot 'log-in' to GMX webmail at all.....because the log-in form simply doesn't show. I wasn't aware of this, because in SeaMonkey I always use the Mail Client itself......it's about the only browser where I've never bothered with webmail. Never seemed any point, since the built-in mail client is a part of SeaMonkey itself......and I've always preferred email clients to webmail.
Mike. 
Puppy "stuff" ~ MORE Puppy "stuff" ~ ....and MORE!
_______________________________________________________
@mikewalsh You didn't answer my question.
To illustrate my problem again I downloaded your Pale Moon "portable", expanded it in the /root/Downloads folder and ran LAUNCH. It works.
I then copied the PaleMoon folder to /mnt/home, ran LAUNCH, and it doesn't work. It can't work because your build includes a glibc228 folder This folder originally contains many symlinks, all of which die on their way to a FAT32 stick. The result is an unusable 'portable', hence my request to include a warning for your unsuspecting users.
@MochiMoppel :-
Hallo again, Mochi.
Now; a "warning" may not be needed, after all. I've done some re-building of the 'glibc-228' directory, to remove all sym-links; basically, all libraries have been re-named to their "link" equivalents, and the corresponding links removed. (Most of the re-naming was straight-forward; however, I wasn't at all certain about duplicating "ld-2.28.so", re-naming it to "ld-linux.so.2" and then substituting it for the sym-link of the same name, but - touch wood - it doesn't appear to be misbehaving itself.)
Posting this from the current, v31.4.0 32-bit Pale Moon 'portable', running on a 16 GB, SanDisk Cruzer 'Glide' FAT32-formatted flash drive.
-----------------------------
If you'd like to give this a try, you can find it here:-
https://mega.nz/folder/CTIg2TAA#c3g08IWHY4ZBiGbljpEGpA
I've labelled it as a 'FAT32' build just for now. It's running A-OK for me here - YouTube and the Beeb's iPlayer are quite happy - but I shan't label it differently until it's been tested by others, specifically running from a FAT32 stick. If you're happy with this, I can use this 'experiment' as a guideline for building other portables in future, bearing in mind what you've said here. 
Let me know if this works for you, please. The 'Menu-entry' option won't work, of course; although the .desktop file & icon are only copied (then deleted when removed), there's a single sym-link from 'LAUNCH' to /usr/bin/palemoon.....so that option IS untenable. It'll still run fine from the 'LAUNCH' script in purely 'portable' mode, of course, which is, I believe, how most people will use it.
I'll need to mention - for future builds - that the MenuEntry option won't work if running from FAT32, that's all.
EDIT:- I may have spoken too soon! It's perfectly happy running from FAT32 in Xenialpup 7.5. Running like this under Slacko 5.6.0, however, is a different story. Massive amounts of artifacting; videos show up in only certain 'negative' colour combinations.....even trying to write a post for these forums, as soon as you click on the 'Editor' window, everything disappears... 
(This may be due to my Nvidia GPU, and having to run the nouveau driver here. The Nvidia .run file won't compile for me, 'cos this 560 is very much a Frankenpup.....nothing standard about it at all; DPup Stretch kernel, glibc 2.20 'upgrade', various EFI bits filched from Tahrpup 6.0.6 ( had to do this to get it to run on this HP desktop rig, because it normally stalls at "can't find VESA BIOS extensions" - this is a UEFI machine, y'see)). 
Mike.
Puppy "stuff" ~ MORE Puppy "stuff" ~ ....and MORE!
_______________________________________________________
You should be able to create a file on a fat32 or ntfs file system
and format the file to contain an ext3 or ext4 file system.
In other words, a duplicate save file, just for portable apps, if you like.
For example, I created a 512MB file on /mnt/home/ named save3
I formatted save3 with an ext3 vfile system
Then I mounted the file system in the save3 file on /mnt/dave4/
Then I copied the extracted files of Opera-portable 92.0.4561.33 to /mnt/dave4/
(poor choice of file names)
Like this:
Code: Select all
# cd /mnt/home/
# dd if=/dev/zero of=/mnt/home/save3 bs=1M count=512
#
# mkfs.ext3 /mnt/home/save3
#
# mkdir /mnt/dave4
# mount-FULL -o loop /mnt/home/save3 /mnt/dave4/
then clicking the LAUNCH button ...
YouTube looks good. Don't know anything about iPlayer but overall impression is good - so far
The 'Menu-entry' option won't work, of course;
What is the 'Menu-entry' option? The Menu-Add and Menu-Remove scripts work as expected. Tip: If you replace jwm -restart with jwm -reload you can avoid screen flicker since JWM doesn't need to redraw the screen when only menu entries change
there's a single sym-link from 'LAUNCH' to /usr/bin/palemoon.....so that option IS untenable.
The other way round. It's a sym-link to LAUNCH (on FAT32). That's not a problem and it works. You can always link to FAT32, however you can't link within or from FAT32
Running like this under Slacko 5.6.0, however, is a different story. Massive amounts of artifacting; videos show up in only certain 'negative' colour combinations.....even trying to write a post for these forums
Can't confirm. Seems to run nicely in Slacko 5.6.0. I'm now posting from it. If you have problems then I assume that the problems occur no matter if your target partition is FAT32 or ext.
@MochiMoppel :-
Mm-hm. Yes, strictly speaking you're right; the sym-link is in /usr/bin, therefore on an ext format. Thanks for the info, BTW; I wasn't aware that sym-links would work at all with FAT32!
MochiMoppel wrote: ↑Sun Nov 27, 2022 10:27 amRunning like this under Slacko 5.6.0, however, is a different story. Massive amounts of artifacting; videos show up in only certain 'negative' colour combinations.....even trying to write a post for these forums
Can't confirm. Seems to run nicely in Slacko 5.6.0. I'm now posting from it. If you have problems then I assume that the problems occur no matter if your target partition is FAT32 or ext.
Uh-huh. Yes, in my case it has nothing to do with format. My Slacko 5.6.0 is a bastardised "Frankenpup" of biblical proportions, unfortunately. It has stuff from DPup Stretch & Tahrpup, battleshooter's 'glibc-2.20' upgrade, and much of what it runs is from a Xenialpup chroot. And it's all due to the fact that a pristine Slacko 5.6.0 simply will not boot on this UEFI machine. It invariably stalls at "can't find VESA BIOS extensions".....for the simple reason it doesn't HAVE a BIOS. It uses UEFI instead.
It was always my favourite 32-bit Puppy when I had the old Compaq desktop, but things didn't behave themselves at all when I tried running it on this new machine. Hence the Mary Shelley treatment!
---------------------------------------------
This re-built version of Pale Moon is perfectly happy on the FAT32 stick under any other 32-bit Puppy. It's JUST my beloved Slacko 560....(grrr!)
I'll see about using this technique with some of the other portable builds over the next few months. Thanks for testing.....AND for the tip about
Code: Select all
jwm -reloadI'll give that a try. Cheers! 
Mike.
Puppy "stuff" ~ MORE Puppy "stuff" ~ ....and MORE!
_______________________________________________________
mikewalsh wrote: ↑Fri Nov 25, 2022 5:43 pmI'm wondering if there might be any way in which a portable app could be made to think that a sub-directory - within its own directory - was the user's $HOME directory rather than needing to search the system to find it.
In other words, convince it to create its configuration directories/files within a pseudo-$HOME directory instead of looking for the "real" $HOME directory. What's your opinion? Is there a way it could be done? Is it even 'do-able'?
Yes, it's 'do-able.'
Hello and Happy Easter Wishes for all of us, here are some retro builds;
- 2.53.16 3DNow - usually cpus that have 3dnow, but lack cmov instruction set ( so Amd K6-x series (k6-2/k6-2+/k6-3/k6-3+, Geode LX, some Via cpus (C3 Samuel 2 and C3 Ezra are the target cpus, but also works with classic Athlon/Duron), built under Debian 8 (the latest distro with i586 support) with gcc-7 which is required to run under Debian 8/9, under Debian 10/11 based distros run by out of the box. Of course it works with other 3dnow capable cpus on Debian 8 or newer 32bit Debian based distros, but this is only relevant for low-end low-clock Duron/Athlon configurations with low amount of memory, because it will probably run faster than IA32 builds. all past and future builds will be available here
- 2.53.16 IA32 - usually cpus that have cmov, but lack sse instruction set) like Pentium Pro, PII (and Mendocino Celeron), Athlon (from Argon to Thunderbird), Duron (Spitfire), built under Debian 8 with gcc-7 which is required to run under Debian 8/9, under Debian 10/11 based distros run by out of the box. all past and future builds will be available here
- 2.53.16 SSE - sse required (PIII and Celeron derivates (Katmai, Coppermine, Tualatin), Athlon Xp/K7 based Sempron/Geode NX or Morgan core or newer Duron), Via C3 Nehemiah, minimum glibc 2.19 required, Debian 8 (Jessie or hihger supported), built under Debian 8 with gcc-7 which is required to run under Debian 8/9, under Debian 10/11 based distros run by out of the box. all past and future builds will be available here