Puppy Linux Discussion Forum

Fool’s Rush in, and all that.

Despite my misgivings and most likely as a means to again put off the things on my ‘Must-Do’ LIst, I’ve decided to explore the possibility of upgrading the glibc which was built-into Tahrpup64.

Consider this a Proof of Concept. The only possible benefit I can think of is that such upgraded Tahrpup64 would be enable it rto run current web-browsers. With its current glibc libraries it might be possible to run ‘mozilla’ web-browsers which themselves provided glibc libraries. But to run ‘chromium’ web-browsers now requires that they be in a chroot, i.e. a more up-to-date operating system run from within Tahrpup64. The potential downsides of this exploration are that (a) It won’t work, perhaps entirely my fault ; or (b) it does work but breaks other applications dependent on Tahrpup’s older, built-in, glibc libraries.

I chose Tahrpup64 for this exploration because (a) Slackware and debian/ubuntu have evolved in different directions as to where to locate 64-bit libraries; (b) I just ‘woofed’ a new Fossapup64 which is compatible with Ubuntu Fossa Focal and plan to use its glibc libraries which, I think, are the latest or at least very near so --they are glibc 2.31; and (c) I’ve previously remastered tahrpup –albeit the 32-bit version-- so have a good idea where files may be located.

Step 1: Prepare to Obtain the glibc libs from Fossapup64_9.6. I booted into that Puppy and used pfind. This, fortunately, revealed that the glibc libs on that system had been recorded in text files in /var/packages/builtin_files folder. [IIRC, Tahrpup64, in /root/packages there will be analogous lists for which glibc files will have to be removed]/ Examining that folder revealed 3 potentially relevant files: glibc, glibc_locales and glibc32. The last made me wonder to what extent Fossapup64_9.6 may already be 'multi-arch' capable. Opening these files in a text editor indicated that roughly a thousand libraries relating to glibc were built into fossapup64. Fortunately, these lists also identify the folders where the files are located and there are much fewer folders. Unfortunately also revealed not all relevant files were in a 'lib' folder. Some were in /etc. I don't really understand /etc so hate having to deal with it. Made copies of the aforementioned /var/packages/builtin files. Note to Self: remember to copy these list-files to the appropriate location in Tahrpup64.

Also to be noted. Some of 9.6's relevant builtin files are in /lib. Not sure had I chosen VanillaDpup as source what would happen. Fossapup64 pre-dates the move to 'usr-merge' where NO user installed files can be in /lib. But this is a rebuild creating a new 'gdrv.sfs', so that 'rule' probably doesn't pertain.

Within the builtin_files folder was also a file indicating that gtk3 libraries are present. As modern browsers require gtk3, I decided to copy that file (and later include relevant gtk3 libraries): better to have them and not need them than need them and not have them. But will the rebuild already have the 'infra-structure' to use them?

FYI, I've attached copies of the built-in lists.

Step 2: Obtain copies of all relevant files. Not yet done.

Stay tuned, check back later for edits/updates to this post. And please don’t post replies until I have reported some progress such as that I've actually constructed a rebuild and tried to boot into it; unless you know that I've already made some fatal error.

Ah, I just realized that some of fossapup's builtin glibc files are in 'x86_64-linux-gnu/' folders, such as /usr/lib/x86_64-linux-gnu/audit/sotruss-lib.so; and Tahrpup64 doesn't know how to handle such folders. The work-around was to move all such files to '/lib' folders, with the 'x86_64-linux-gnu/' folders being symlinks . But that is just one of three possible ways to 'work-around'. Maybe the replacement initrd overcomes that hurdle? Maybe not? We'll have to see. Note to self: The next time you have a great idea re-read the first sentence of this post. This is already beginning to seem like a repetition of your 'breed panda-like Siberian hamsters' debackle.

Ah, another wrinkle. Decided to put off copying libs to freshly examine Tahrpup64-6.0.5's structure. Found a Tahrpup64-6.0.6 in 'Storage' I had completely forgotten. Wondering if it might be a better candidate I used https://rockedge.org/psearch/ to look for discussions about it. Although I decided it best to stick with 6.0.5, this post https://oldforum.puppylinux.com/viewtop ... 14#p986014 revealed that I should also update openssl. Back to using pfind to identify fossapup64's openssl libraries. Dah. Of course, concentrating on the process I forgot the destination: the entire reason for updating glibc is to obtain one which can make use of a sufficiently current openssl that current web-browsers can be used.

So there is also a 32-bit glibc in 64-bit Puppys? What is this for, to be able to run 32-bit applications? LOL, seems a bit like a mess similar to the situation with trying to run 32-bit Wine applications with a 64-bit OS. So glad I'm sticking with the "simple" 32-bit system as long as I can.

Well, here's where things stand:

Copied all files relating to glibc, gtk+3, openssl, glibc32 and glibc_locales from fossapup64 into a folder named gdrv_tahr64_6.0.5 and dir2sfs'd that folder. The glibc32 files came from a lib32 folder and I doubted tahr would know what to do with that folder . So I put it in /root/my-applications/lib in the gdrv. I suspected that tahr's and fosa's glibc_locales were petty much the same. But as most of the relevant files were in one folder I included fossa's in the gdrv.

I then unpacked puppy_tahr_6.0.5.sfs and deleted any files which might conflict with those in gdrv. Then repackaged it.

Which brings me to what to do about init. Two options: (1) Edit fossapups to work with tahr and auto-mount the gdrv; and (2) edit tahr's to auto-mount the gdrv. My initial impulse was to do '1' --more likely to have been written with what is to be an 'upgrade-to-tahr's' applications in mind. But just a visual examination of their respective extracted initrd.gz's reveals, they are very different animals.

So I think the way forward is to go with '2'. An cursory examination of tahr's distro-specs and init indicates that it already has been configured to make use of adrv and zdrv, so adding a gdrv should not impose an insurmountable hurdle. But I'll have to study them with a fresh mind --likely not before the day after tomorrow.
In the meantime, suggestions, recommendations are welcome. I've attached copies of the relevant initrds and distro-specs for the curious.

The purpose of updating glibc libraries was to be able to use current web-browsers while continuing to use the less ram-demanding operating system and other applications of tahrpup64. But even less demanding are the operating system and applications for tahrpup32.

peebee has just published a 64-bit compatibility SFS, https://www.forum.puppylinux.com/viewto ... 284#p78284. The recipe for its use are to first swap the 32-bit kernel (including zdrv (drivers) and if separately packaged fdrv (firmware) with a 64-bit kernel, reboot then SFS-Load the 64-bit compatibility SFS.

I am posting from tarhpup32 using the latest palemoon 64 having swapped in F-96's 6-series 64-bit kernel. On boot-up pupsys-info reported that about 200 mbs of RAM was required; after SFS-loading the 64-bit compat SFS about 300 Mbs. At the moment pupsys-info reports 503 Mbs are being used. This is about the same, maybe slightly less, than xenialpup32 used yesterday when I preformed the same procedure. IIRC, it is significantly less than running a web-browser in a Chroot.

Edit: Subsequent exploration revealed that some 64bit Web-browsers could be run using less than 350 Mbs of RAM. https://www.forum.puppylinux.com/viewto ... 793#p78793

Edit: peebee's subsequent modification of the 64bit Compatibility SFS eliminated the attachment issue mentioned below.

Yesterday, on the above described xenialpup32 I was able to run the latest browsers based on both mozilla (firefox-quantum) and chromium. I was able to download a pet (albeit small) and post to the forum. But in such post I was not able to provide an attachment. After publishing this, I'll see if I can edit it to do that.

That went well. This is a keeper.

Edit. I am now posting using MikeWalsh's Brave64-portable, which is based on Chromium 104xxx. Pupsys-info reports 733 Mbs of RAM being used. I'll test whether attachments present a problem. It does. Brave crashed.
By the way. While Brave's tool bar icons displayed properly, those of palemoon didn't. They were just 'x''s.

Let's see how well firefox quantum does.
Posting using MikeWalsh's firefox-portable at version 108. Pupsys-Info reports 986 Mbs being used. I don't have much hope about making an attachment. But will try after posting this.

Nope. While Brave crashed when I tried to upload the attachment, firefox didn't even get that far. It crashed as soon as I clicked the Attechment button. Although I have 16 Gbs of RAM it could be a memory thing --the way browsers handle RAM?. NOte the difference between how much the different browsers used. But remember that this setup is still basically 32-bit. IIRC, at one time we had a problem with attachments relating to glib-schemas which had nothing to do with mixing architectures.

I think such efforts are a great benefit to the Puppy community.

One of the greatest complaints against Puppy is that we move on too fast - to new versions of Puppy - before ensuring the old versions work correctly and have adequate software available.

We end up with a plethora of software that becomes outdated and cannot (easily) be ported to a different pup.

Anything that keeps an old pup in play - or that allows new functionality without forcing us to drop our favourite Pups - is a wonderful thing and to be applauded loudly.

EDIT - This is particularly true for those of us who try to keep Puppy useful for those who are handicapped or elderly. Such users struggle to adapt to new devices or operating systems and benefit greatly from continuing to use one familiar system. It is appalling that the web often unnecessarily morphs in ways that isolate such people. (Even banks and government organisations who should know better than to overcomplicate basic functions seem to follow Google Chrome wherever it leads. And no - many of the changes have nothing to do with security. Banking using 2FA or similar does not have to require the latest browser... It is just that some institutions are getting lazy and letting Gooogle decide how their customers are treated)

I'm posting from tahrpup32 using portable Palemoon64 having sfs-loaded peebee's 64bit compatibility SFS and also registering a "shinobar/traditional build" of portable-wine. This is essentially the same configuration I had here, https://www.forum.puppylinux.com/viewto ... 724#p78724 except now using tahrpup instead of xenialpup.

PupSys-Info's reports regarding memory usage are essentially the same. However, xenialpup appeared to do much better (by a couple hundred MB) when running the graphic program irfanview under wine.