Google-Chrome 'portable' 64-bit browser - (with updater!)

[mikewalsh]

@Barkingmad :-

Hiya, Barking. I would have answered you back earlier, but I've been experimenting. And I've made some interesting discoveries.

Recently, the current Chrome had quit working with Xenialpup64, as well as with Tahr64. I tried baraka's seemingly "nutty" workaround; crazy as it sounds, it works for Tahr64. And that got me thinking; might the same cross-platform trick work for Xenialpup64, too?

As it turns out; yes; it does. In fact, you don't need to install all items of the normal GTK-3.0 upgrade package; just libgdk-3.0.so.0.1800.9. Replacing this sole 64-bit item with its 32-bit equivalent makes a ton of 64-bit stuff - mostly browsers! - all suddenly work again. Makes no sense, does it..?

Anyway; if you unzip the attached tarball, and drop the resulting lib into /usr/lib - overwriting the in-built version - and attempt to start Chrome again, I think you'll find it will start now.

This is at your own risk, you understand. Unless you want to leave it for a day or so; I'll try and figure out a way of doing this that will save the original 64-bit version to a safe location, so you CAN replace it if necessary.

Mike.

[baraka]

@mikewalsh

Hi, I'll explain briefly what I think it happens in Tahr64, maybe it will help you. (everything is about Chrome 95)

LD_LIBRARY_PATH should have priority over /usr/lib /lib etc (as a matter over everything in ld.so.cache). Fact explored by your chrome-pup script. Another fact is that gtk library calls the gdk one and they should match (same version stuff, I think).

Now, for some obscure reason the gtk from /chrome/lib calls the gdk from /usr/lib, because in this case chrome disregards the LD_LIBRARY_PATH variable (I tried every combination, with export blabla, add my config file into /etc/ld.so.conf.d/, rebuilt ldconfig cache with a path to /chrome/lib, and nada, no avail).

There are three options (my poor educated guess):
1) use only the system's one (after update) from /usr/lib which seems for me the better idea. Removing the system's libgdk-3.so.0.1000.8 library will break every other stuff that depends on it. And it will require a hack for every program that will not fall gracefully on gtk2 (granted that gtk3 is not big in tahr's world) and need that library.

Solution:
- update tahr
- delete the libgdk-3.so.0 libgtk-3.so.0 and libpangoft2-1.0.so.0 from /chrome/lib (the last one is required because it should match gtk library). All three of them will fall on /usr/lib.

Negative impact: marginal. I found that the File Chooser dialog window (that with squares instead of letters) has a much uglier design.

2) use only those from /chrome/lib.

Solution:
delete the libgdk-3.so.0.1000.8 library from /usr/lib and live with the consequences.

3) update the system using the gtk and gdk libraries from /chrome/lib. Chrome will work like a charm, but it'll break other things (kinda like option 2) - for example nvidia-settings.

In the end, you were right. Install 32bit library has no relation with the meaning of the word "install". It's just delete (same as option 2).

@Barkingmad

I retested in xenial64, fresh install. Same conclusion, use LAUNCH_NL. It will work regardless of those updates, purely independent. If you want for some strange reason the LAUNCH script, what I said about Tahr64 applies in your case as well.

Just a caveat. My error is this when I use LAUNCH:

Code: Select all

symbol lookup error: /initrd/mnt/dev_save/Downloads/Google_Chrome-portable/chrome/lib/libgtk-3.so.0: undefined symbol: gdk_anchor_hints_get_type

I can't reproduce the permission error. Maybe is something else entirely.

Hope this will help. A good day to you all.

[Barkingmad]

Hello
Reporting back.

I have now tried LAUNCH-NL. I get the same permission error as before, I have not seen the 'symbol lookup error' that baraka is getting.

I have also tried the xxREADME scripts in Mike's package and they don't work either - lots errors along the lines of commands not found. I could repeat this and post the console output if would be helpful.

UPDATEChrome seems to work in that I see the prompts but now the output from trying LAUNCH is as follows:

Code: Select all

chown: /initrd/mnt/dev_save/Xenialpup75/Google_Chrome-portable/chrome: No such file or directory
sh: /initrd/mnt/dev_save/Xenialpup75/Google_Chrome-portable/chrome/chrome: Permission denied
Script completed hit RETURN to close window.

I haven't tried anything with the libs as yet.

Mike, do you still have a package for download of the last version you've found to work with Xenial? I could try that to rule out something odd with my install.

I think that's all to report for now.
Will

[baraka]

@Barkingmad

It's not the libs. I have a suggestion, nothing special. Do every step from LAUNCH script manually in terminal. Something peculiar should appear. If is somewhat trivial and you already done it, sorry (wait for Mike ).
LAUNCH script has to have root privileges - pls verify that. As a matter of fact the entire Google_Chrome-portable directory just after untar has to be root.

[mikewalsh]

@Barkingmad :-

Will:- If you go into the URL in the first post, you'll find a directory for '91-series'. This is the last version that worked with all Pups without question; baraka's assertion that this is all happening with Chrome 95 isn't technically correct, as it's been going on for a few months now.....

Let us know what you figure out, please. I've got too much else going on to be able to spend ALL my time figuring out one single app, much as I would like to. Feedback from others doing a spot of testing on the community's behalf will only benefit us all in the long run.....browsers are a constantly-moving target, after all. There's always something needing a workaround with the damn things, though we can't do without them, unfortunately.

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

@baraka :-

Yup, you've got that right. The 'Launch' script is written to set & re-enforce 'spot' permissions in the required places every step of the way, but it is, of course, completely "root" immediately after unzipping and BEFORE you fire it up for the first time.

Mike.

[baraka]

@mikewalsh
Yes, yes, it has months. I chose Chrome 95 as a starting point, so everyone will speak about the same thing.
Imho, they are minor glitches and the important thing is that old systems can run new software.
If chrome works, everythig works, and I'm not half joking.
I'm sorry that I can't provide a real help, but I'll test everything.

[mikewalsh]

@mikewalsh
Yes, yes, it has months. I chose Chrome 95 as a starting point, so everyone will speak about the same thing.
Imho, they are minor glitches and the important thing is that old systems can run new software.
If chrome works, everythig works, and I'm not half joking.
I'm sorry that I can't provide a real help, but I'll test everything.

@baraka :-

The bit I still can't figure out is this; if /chrome/lib's gtk-3 is calling /usr/lib's gdk-3 - and not finding it! - what is it then doing? "Falling back" to the LD_LIBRARY_PATH command it should have followed in the first place? Because from my research:-

• gtk is the GIMP Tool Kit.....but

• gdk is the GTK+ Drawing Kit

So; which one calls which? ATM, Chrome - with this workaround - is finding gdk3, but it's the wrong ELF class, and obviously can't use it. But it must BE finding gdk-3 somewhere, because Chrome runs and renders perfectly. Which begs the question.....what on earth is going on? If I could understand the "flow-chart" (or sequence of events, like which lib calls which one next, etc), I might be able to figure out a more permanent 'fix' for this.

The goal is as it's always been; to have a single package that will run with as many Puppies as possible.

Mike.

[williams2]

which one calls which?

This picture of the gtk system from Wikipedia might help visualizing the parts of the system and how they are linked together.

640px-GTK+_software_architecture.svg.png (18.12 KiB) Viewed 8376 times

All the parts of the Gtk system seem to be all linked and interlinked closely together.
to be truly compatible, all the shared object files really should be compiled at the same time, in the same environment that was there when the rest of the operating system's shared object files were compiled.

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

GDK ... is a library that acts as a wrapper around the low-level functions provided by the underlying windowing and graphics systems.

[mikewalsh]

@williams2 :-

Cheers, mate. That's much appreciated, even though it only confirms what I already suspected.....that the whole GTK3+ shebang is a total PITA to work with!

Anyways.....

I've figured out a viable workaround for now. Lord only knows how long it'll be before I have to start tiffling about with it all over again, but for now, this will do what we need.

Basically, I've used the 'grep' command to search for a text string in the /etc/os-release file in both Tahrpup AND Xenialpup. The browser package now contains both 32- & 64-bit versions of the GDK-3 lib in use by Tahrpup and Xenialpup, tucked away in a separate sub-directory inside the 'DATA' directory. If either of these two Pups are detected, the native 64-bit version of libgdk-3 is swapped for the 32-bit version, after which Chrome fires up as normal. Upon closing the browser, the 64-bit native version is restored to its rightful place...

It's an awful, horrible 'hack', 'tis true, but since things have been this way for some months now, I don't see it changing anytime soon. It does, however, mean that we still (for now) have a 'one size fits all' package for several of the 64-bit Pups. I'll probably 'retro-fit' this workaround into the other clones, as & when new releases come out.

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

It's been tested in Tahrpup64 (and Quirky April64 7.0.1, which uses a lot of Tahr's infrastructure), Xenialpup64, and I'm currently posting from it in Bionicpup64. In all cases, the 'auto-detect' routine is doing its 'thang', and swapping stuff as & when needed. Which WAS the whole point of the exercise.

You can find the re-jigged version at the usual URL in post #1. Enjoy, mes amigos.

Mike.

[baraka]

@mikewalsh

I'm not so sure anymore how many months the bug has. I had only one other version of Chrome between 91-95 (and I throw it away).
I'll repeat: Xenial64 works OOTB with LAUNCH_NL.

"Falling back" to the LD_LIBRARY_PATH command it should have followed in the first place?

Yes, for sure. I'm REALLY puzzled myself. And I can't change that order.
The 32bit library is irelevant, you could have used in your script only remove/restore and still achieve the same result.

Thanks very much for the interest and effort. If I'll find a better solution I'll send a message (but I doubt it). That hack is way too ugly

@williams2

Following your comment (thx), I've tried the hail mary approach - update everything related to GTK - and I ended up breaking everything, including WM, and Chrome still didn't start.

[mikewalsh]

I'll repeat: Xenial64 works OOTB with LAUNCH_NL.

Mm. Curious.

You're definitely correct on that statement. Xenialpup64 will now run Chrome with the LAUNCH_NL wrapper.....and experimenting now shows that Bionicpup64 does, too.

Google have obviously been 'tweaking' the build recipe again, which in this case is no bad thing. It means more Pups will now run Chrome with their own, native GTK3+ stuff (and other deps.) Until recently, neither Xenial nor Bionic would run Chrome without making use of the included 'lib' directory.....and now, they don't need to. Nice one.

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

As a side observation, this just shows how long stuff takes to percolate down through the eco-system. When battleshooter helped me out with the included libs directory, nearly 5 years ago now, she compiled many of the dependencies from scratch. Interestingly, she used the source code for the version of GTK3+ that is standard for Fossapup, which was until recently the only Pup that would run Chrome via the LAUNCH_NL wrapper.

I find it curious that it took nearly 4 years before that version of GTK3+ was in common use by Ubuntu.....who, like many others these days, are almost obsessive about keeping up with the very newest versions of everything. Why so long?

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

I've re-jigged & re-uploaded the current version again. The 'LAUNCH' wrapper now only performs the GDK-3 'swap trick' if Tahrpup is detected. For everybody else, you can now use the 'LAUNCH_NL' wrapper to run Chrome.

(*sigh*)

Have fun, guys.

Mike.

[Barkingmad]

Hello MIke
Do you never sleep?

I've downloaded your very latest effort and tried it.
Both versions of the Launch script still leave me with the permission denied error. I realized the the PROFILE directory and it's subdirectories are made so it seems to run as far as the mkdir lines at least. I have tried to follow the paths you have used and looked at the properties each of the directories and the big 'chrome' file itself. All that I've checked have 'read', 'write' and 'exec' ticked on all three lines.

I will be able to try a Chrome 91 series on Xenial and probably 91 and the troublesome 95 on Bionic but will have to be later in the week.

Thanks for all your efforts
Will

[mikewalsh]

@Barkingmad :-

Do you never sleep?

Heh. I tell ya one thing for free; the older one gets, the more disjointed one's sleep patterns become. On top of which, I'm having my first brush with sciatica, and I am NOT enjoying it one little bit.....

Anyhoo. I've done yet another re-jig. I got to thinking; it would be easy enough to combine the two 'LAUNCH' scripts, so.....there is now only the one. The wrapper script auto-detects if it's running under Tahrpup64, and employs the libgdk3 'swap trick' if it is. Otherwise, under Xenialpup64, Bionicpup64 & Fossapup64, it runs with the native GTK3+ set-up to be found in each Pup. I've been testing this extensively this afternoon, and am finally satisfied that all is functioning as it should.

Since most 64-bit Pups appear to be happy running with their own GTK3 stuff & other deps, it made sense to combine the two wrapper-scripts into one. It cuts down on the confusion, and the one fly in the ointment, Tahrpup64, is taken care of by the auto-swap trick with the 32-bit version of libgdk3. This requires no action on the user's part, and happens automatically during startup of the browser.

This will be the standard operating mode of the portable clones for the foreseeable future.....or at least until "Big Brother" decides to chuck another spanner in the works again..! Would you be good enough to test it, and see what happens, please?

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

The new version of Chrome-portable can be found at the usual link in post #1. As always; d/l, unzip, move the portable directory anywhere you like.....preferably outside the 'save'. Click to enter, click 'LAUNCH' to fire it up.

Enjoy.

Mike.

[baraka]

@mikewalsh

I've tested Chrome 95 and LAUNCH_NL in Xenial64, Bionic64, Fossa64 - I found no problem. The test consisted in some youtube stuff, google maps and few random pages.
As a sidenote, I'm really starting to like Fossa, but because I began this discussion with Tahr64, I can't stop now.

The hack is bad, I mean really bad. Chrome works, no complaints here, but everything that requires gtk3 will crash.
Experiment: start Chrome and then, as Chrome is running, attempt to start Firefox Quantum. It will fail.
That 32 bit library does nothing. And if LAUNCH crashes, you could be stuck with it, an even worse situation.

The best solution, an official gtk3 update for Tahr64.

If not, I propose removing these files from chrome/lib/, as I said before.
libgdk-3.so.0
libgtk-3.so.0
libpangoft2-1.0.so.0
After, I encounter no difficulties in about a week or so with the LAUNCH script. But I realize that others should have a go before a change; and I know that Tahr is old...

Sorry, sciatica is bad, literally a pain in the ass.

LE: In fact, if you trash the whole gtk package from your added lib directory, the dialog windows, like file chooser, will look a lot better.

[mikewalsh]

@baraka :-

Hm. In-ter-esting, yes indeedy!

I did a bit more experimenting. Taking your suggestions as a starting-point, I've done away with the 'hack', and also tried out your suggestion of removing libgdk3, libgtk3 and libpangoft2 from the 'lib' directory, thereby giving the browser no option but to use the system libs in their entirety.

It all works, very sweetly......and proves, conclusively, that changes have definitely been made to the Chromium base code that's at the heart of all these browser 'clones'.

The single 'wrapper script' still uses grep to detect whether it's running under Tahrpup, but only in order to implement LD_LIBRARY_PATH if needed. For all other Pups, they run with their own native dependencies.

I've not only rebuilt Chrome one final time, I've also rebuilt Iron-portable, Slimjet-portable and Ungoogled_Chromium-portable, too. These have all been tested in Xenialpup, Bionicpup and Fossapup; for Tahrpup I'm actually testing it under my personal 'analogue'; a highly-modified version of jrb's 'lite' spin on Barry's experimental Quirky64 'April' 7.0.1 from a few years ago; this employs mostly Tahrpup infrastructure, so is a good alternative to test the Tahrpup 'mods' on.

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

I'm guessing this has been at the heart of all the gtk3 'issues' with these browsers over the last 3 or 4 years; partly due to periodic conflicts between multiple versions of GTK3+, and partly due to my own lack of understanding of how best to compensate for & work around this. Thanks to your own investigations, we've made steps forward once more, so.....ta very much for that, lad! Much appreciated.

Mike.

[baraka]

@mikewalsh

Thx, I'd like to be more knowledgeable, to provide a real help, unfortunately, that isn't the case.
The story with LD_LIBRARY_PATH I think is related to Secure-execution mode (from ld manual) - an opinion best served with a jar of salt.

In few years I'm expecting Chrome to package its own libraries, digitally signed. And by then, it will remain only one possible test: starts or not.
It's clear that I don't like Chrome (and all the clones, but I'm glad to find Iron working again, Iron93 in tahr64 is flying as it should). And even more clearly that it's the best browser because... I think you know better.

It's important to have fundamental software, usual user software, reliable and simple to install. To put it simply: great work, sir!
Now I remembered... I'll start pestering other people with another one of my favorite subjects: installing nvidia driver.

[Barkingmad]

Hello, I'm back

Mike
I've now tried your very latest Chrome95

On Xenial64 I still get the same permission error as all along.

Tried booting Bionic64 v8 from a CD and it runs. There were a load of errors in the console that I managed to loose while trying to copy and paste to this post but it seems to run OK.

Differences: Xenial is a frugal install on a NTFS hard drive with a save file. Bionic was booted from CD fully in RAM and no save file.

Now to try Chrome 91 on my setup.
Will

EDIT
I have now tried Chrome91 on my Xenial64 and this one also has the permission error. It looks like the problem is with the Xenial install, I might have to move to the Xenial thread but I've done enough with this for tody.
W

[williams2]

Ntfs and fat32/vfat file systems do not have attributes like read, write and execute permissions that Linux file systems have. When Linux mounts an ntfs or vfat file system, it sets the same permissions for every file and dir. Those permisions are set when the file system is mounted.

By default, user spot can not see any files or dirs in an ntfs/vfat file system mounted this way.
You can mount ntfs/vfat so that spot can see, read, write and execute those files.
If you want to make /mnt/home/ accessible by spot, and if /mnt/home/ was mounted automatically by Puppy (because that is where the save file is) then you would need to edit the init script in initrd.gz to allow spot to have access to files in /mnt/home/

If you put Chrome files in /mnt/home/
and if you run Chrome as user spot,
then Chrome will not be able to access file in /mnt/home/
including any Chrome files that are in /mnt/home/

To allow spot access to /mnt/home/ you need to do something like this:

ntfs-3g /dev/sda4 /mnt/home -o umask=0002,no_def_opts,noatime,rw,silent,allow_other,gid=100

This mounts /dev/sda4 on /mnt/home/
umask=0002 allows rw access if you belong to the group that /mnt/home/ belongs to
allow_other is necessary to allow spot access
gid=100 makes /mnt/home/ owned by group 100 (disk). spot is a member of group disk.

With this configuration, spot can access rw the ntfs file system mounted on /mnt/home/

If spot can not access /mnt/home/ I don't think Chrome can run as user spot if the Chrome files are on /mnt/home/

Chrome should be able to run if the Chrome files are in /opt/ or in /tmp/ (the permissions and/or ownership of the files might need to be configured first.)

[williams2]

If the files in a portable package are contained in an sfs file (a file containing a Linux squashfs file system)
then each file has permissions set. If the permissions are set correctly, it should run properly.

Again, if you are trying to run as spot, and the executables and/or data files are not accessible to spot, I don't think that would work.

[mikewalsh]

@williams2 :-

Probably why I have no problems with running them in my set-up. Ext3 throughout - with the exception of the tiny FAT32 sda1 /boot partition (necessary with UEFI-equipped machines, even if running in 'legacy' mode, as I do) - and all 'portable' browsers are run from a dedicated directory on a separate partition, also Ext3.

I've never had the slightest problem with permissions/ownerships. (The wrapper-script for portable Chrome has always set & re-enforced spot ownership every step of the way as it runs through. Would this not work on FAT32/NTFS? I'm guessing NOT in the same way as it does on a Linux-formatted file-system, hmm..?)

Mike.

[williams2]

The wrapper-script for portable Chrome has always set & re-enforced spot ownership every step of the way as it runs through. Would this not work on FAT32/NTFS?

No, the ownerships and permissions are set for all the files in the entire ntfs file system when the ntfs file system is mounted. All of the files and dirs will have the same ownerships and permissions.

The ownerships and permissions can be changed only by remounting the file system.

For example:

Code: Select all

# cd /mnt/home/
# touch puppy.txt
# ls -l puppy.txt
-rwxr-xr-x 1 root root 0 Nov 10 16:42 puppy.txt
#
# chown spot:spot puppy.txt
# ls -l puppy.txt
-rwxr-xr-x 1 root root 0 Nov 10 16:42 puppy.txt
#
# cd /home/spot/
# su spot
$ ls -l /mnt/home/puppy.txt
ls: cannot access '/mnt/home/puppy.txt': Permission denied
$ ls -l /mnt/home/
ls: cannot access '/mnt/home/': Permission denied
$

Here /mnt/home/ is an ntfs file system, mounted with this command:
ntfs-3g /dev/sda4 /mnt/home -o umask=0022,no_def_opts,noatime,rw,silent

I created a /mnt/home/puppy.txt file.
puppy.txt is owned by (user:group) root:root
All files and dirs in the whole /mnt/home/ file system are owned by root:root.
Owner, Group and World can read and execute any file in /mnt/home.
Only Owner can write to the file.
Because I mounted it that way umask=0022

Then i changed the ownership to spot:spot chown spot:spot puppy.txt
There was no error message, but another ls -l shows that the ownership did not change.

Then I became spot su spot
spot can't see the puppy.txt file at all, or anything in /mnt/home/
Of course, files in /mnt/home/ can't be seen and also can't be read or executed.

Chrome Portable should work in /tmp/ which is ram.
Or in the save file, for example, /opt/

[Barkingmad]

Thanks williams2

I will have to try and digest what you've posted but it sounds as though you might have found the root of my trouble.

Should it work as a test if I were to format a spare pen drive to an ext file system and put the portable Chrome folder on that? Which ext version would be preferred?

Thanks again
Will

[Barkingmad]

Hello
An update here. I found a spare 1GB pen drive and used gparted to delete the FAT32 partition that was on it and make and format a new ext2 one using all the space. I've freshly unpacked the portable Chrome files onto the pen and it starts up fine from the LAUNCH script - I'm posting from it now.

Would this apply to the other "Chrome based" browsers and apps that Mike has packaged?

Perhaps a note in the intro post that Puppy needs to be on an ext drive or partition would help other users.

Thanks for everyone's help
Will

[mikewalsh]

Hello
An update here. I found a spare 1GB pen drive and used gparted to delete the FAT32 partition that was on it and make and format a new ext2 one using all the space. I've freshly unpacked the portable Chrome files onto the pen and it starts up fine from the LAUNCH script - I'm posting from it now.

Would this apply to the other "Chrome based" browsers and apps that Mike has packaged?

Perhaps a note in the intro post that Puppy needs to be on an ext drive or partition would help other users.

Thanks for everyone's help
Will

I would guess that probably does apply to any of the 'portables', Will. They're all constructed to run on Linux file-systems, so it stands to reason they need to be ON one to function.

Mike.

[r96chase]

Quick question: how does the "updater" work on this version? Does it just give a notification of when to switch to an updated version or does it automatically update the browser? I'm a bit confused about this tbh.

[mikewalsh]

Righty-ho, gang.

Chrome has now moved to version 96 - v96.0.4664.45, to be exact:-

So for those of you running Chrome-portable, time to get busy with the updater!

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

@r96chase :-

Heh. You've picked the perfect moment to ask this, mate. No, the 'updater' does NOT merely notify you a new version is ready.....this updater script uses wget to download the 'current' Chrome .deb package from Google. It's downloaded, initially, into the portable's directory.

Once downloaded, the .deb package is moved into /tmp. It's extracted, and the existing 'chrome' directory has a couple of things copied out, and is then deleted. The new 'chrome' directory is then copied in to replace it, the odd items are replaced again, and finally a GTK-dialog box informs you when the process is finished.

You should see something similar to this:-

The 'chrome' directory is the only thing that needs replacing. Everything else within the 'portable' remains as-is. (Total time to complete will of course vary from one user to another, dependent on system clock speed & your actual download rates.....YMMV.)

Informing the user that a new version is available is the one thing that's beyond my present abilities, I'm afraid. My advice is to keep a weather eye on the Chrome 'blog', here:-

https://chromereleases.googleblog.com/

Google build many different versions of Chrome, for a lot of different platforms, but if there's been an update to the "Stable Desktop channel", it's generally in the first couple of pages. Just compare version numbers, and if the published one is newer than yours, simply run the updater. It's all automatic, and when the final notification shows up the top of the screen, the new version is ready to go.

(If I can ever figure out just where the Linux Chrome build puts the info about a new version - it does receive it, but the Linux build does NOT have a built-in updater - it ought to be easy enough to grep that info, then running something along the lines of a diff comparison.....followed by triggering the update automatically. But that's for another day.....and will be after I've taken the time to learn more new stuff! )

As long as your Puppy is running on a Linux filesystem, as opposed to LICK or whatever running on FAT32, this manual updater should be totally trouble-free. I've literally just updated myself, immediately before posting this. It definitely works.

Mike.

[mikeslr]

MikeWalsh has greater faith in 'things work as they should' than I. So, if you suffer from a slight case of paranoia, before doing an update, make a copy of the current portable folder. Easy-Peasy if your system has Right-Click [folder/anything] >duplicate --with slightly different name such as Google_Chrome_portable1.
Paranoia aside, caution with new devices is always recommended. The update left me with NO chrome subfolder in 'portable1', thus no functional chrome from it.

Deleting, then recreating 'portable1' and running its update from the terminal produced the same results but also this terminal print-out:

Resolving dl.google.com (dl.google.com)... 142.251.32.110, 2607:f8b0:4006:80d::200e
Connecting to dl.google.com (dl.google.com)|142.251.32.110|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 90769636 (87M) [application/x-debian-package]
Saving to: ‘google-chrome-stable_current_amd64.deb’

google-chrome-stabl 100%[===================>] 86.56M 347KB/s in 4m 22s

2021-11-15 14:53:53 (339 KB/s) - ‘google-chrome-stable_current_amd64.deb’ saved [90769636/90769636]

/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/UpdateChrome!: line 18: ar: command not found Emphasis added.
tar: ./data.tar.xz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
cp: cannot stat '/tmp/chromenew/opt/google/chrome': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/google-chrome': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_16.png': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_24.png': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_32.png': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_32.xpm': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_48.png': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_64.png': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_128.png': No such file or directory
rm: cannot remove '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_256.png': No such file or directory
cp: cannot create regular file '/initrd/mnt/dev_save/Pup-Apps/Google_Chrome-portable1/chrome/product_logo_256.png': No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
EXIT="Exit on timeout"
Script completed hit RETURN to close window.

Have to go out now. Will try to figure out what went wrong later.

Edit Update: line 18 of the UpdateChrome script reads:
"ar vx ./google-chrome-stable_current_amd64.deb"

[mikewalsh]

@mikeslr :-

My bad, Michael. There's two issues at play here.

• Firstly, why have I not written the script to use dpkg-deb - a standard component of every Puppy install - rather than the ar command? It's a pertinent question, and one deserving of an answer.

  All the tutorials I researched for extracting a .deb package via the command-line primarily mention ar as the utility to use.....and dpkg-deb is only mentioned as a secondary alternative, if it's mentioned at all. The main issue here is that Google are very soon planning to move to a new version of the .deb package archive, one which Puppy's version of dpkg-deb will no longer be able to understand. Hence, the use of ar instead.

• Secondly, I admit this is my fault here. Ar is part of the binutils package, which in turn is part of the devX package. Now, I've been doing all this development in jrb's 'lite' spin on Barry's Quirky64 April 7.0.1. I hadn't realised until you mentioned it, but ar is not a default part of most Puppies; the devX needs loading to access it. The only reason I have it 'installed' in Quirky is because the devX package for Quirky only ever came as a .pet package, NOT an SFS as is normal. I'd installed it some time ago, and had completely forgotten it WAS permanently installed.

So; please do me a favour, and try the updater again, this time loading the devX first..? It should work correctly once the devX is in place.

This is in all likelihood at the bottom of other folks who've tried it and found it didn't behave as expected.

Thanks for pointing this out. I'll need to edit the relevant post to add that the devX needs to be loaded for this to work properly......but there was no point in writing the script to make use of a utility that will very soon cease to function for the Chrome .deb. Good catch, BTW..!

Mike.

[mikeslr]

I can confirm that once the devx.sfs was sfs-loaded the UpdateChrome! script works fine*. Nice work, Mike.
But having Uncle Mike deliver nicely packaged and gift-wrapped presents required less personal effort.
--=-=-=-
For any who are RAM-concerned, the entire process only took a couple of minutes; and the devx.sfs unloaded immediately thereafter without any complications.

[mikewalsh]

@mikeslr :-

I can confirm that once the devx.sfs was sfs-loaded the UpdateChrome! script works fine*. Nice work, Mike.
But having Uncle Mike deliver nicely packaged and gift-wrapped presents required less personal effort.
--=-=-=-
For any who are RAM-concerned, the entire process only took a couple of minutes; and the devx.sfs unloaded immediately thereafter without any complications.

I'm trying to lighten my work-load a wee bit, Michael. If I can set things up so that folks can at least update just one single item for themselves, that's one less for me to worry about!

Chrome's about the only one I've found I can do this with. Download links for all the others either go through half-a-dozen or so 'redirects', obscuring the real URL & in the process telling me 'You don't have permission to access such-and-such'......or else the linked item has a specific version number that changes with every release, thus making it problematic to set-up a permanent download link.

(*buggers..!*)

Iron is a 'possibility'. I haven't fully investigated their links yet.

Mike.