64-bit Google-Chrome 'portable' packages

[linux28]

Google_Chrome-portable/chrome/chrome: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: pango_font_description_get_variations

[Mike Walsh]

Google_Chrome-portable/chrome/chrome: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: pango_font_description_get_variations

@ linux28:-

I don't know what you're doing, but you're doing summat wrong.

Chrome should be finding libpangoft2 in its own, self-contained libs directory. For some reason, you've got it looking in the system to find it.....

How are you trying to start Chrome? If you don't use the 'LAUNCH' script to fire it up, then everything else goes to pot, too. It's no good you trying to take short-cuts, because things have been set up to work in a particular way. If you are taking 'short-cuts', then I can't be held responsible for it not behaving itself...


Mike.

[davids45]

G'day Mike W.,

I'm trying your 64-bit Chrome Portable, which runs, but I cannot import my html file of bookmarks.
Chrome seems to do the Import but when I then try to set up the 'imported' bookmarks, they are not there. Just the three default Google bookmarks.

My non-Portable version of Chrome has the imported bookmarks as I want but doesn't seem to offer a way to export them - if that could be what Chrome-Portable wants?

(update) I found opening both Chromes, I can drag the bookmark on the Bookmarks bar from one Chrome to the other and the bookmark will open in the 'new' Chrome. But not the way to do it for >100 bookmarks of which most are not on the Bookmarks bar.

The html file has been OK in all other browsers, portable and 'normal'.

Is this a Spot issue in some way - I haven't yet ventured into that Spot-root minefield.

Thanks for any help.

David S.
(still to test the Vivaldi-64bit-Portable attachment-to-forum-messages oddity).

[linux28]

Google_Chrome-portable/chrome/chrome: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: pango_font_description_get_variations

@ linux28:-

I don't know what you're doing, but you're doing summat wrong.

Chrome should be finding libpangoft2 in its own, self-contained libs directory. For some reason, you've got it looking in the system to find it.....

How are you trying to start Chrome? If you don't use the 'LAUNCH' script to fire it up, then everything else goes to pot, too. It's no good you trying to take short-cuts, because things have been set up to work in a particular way. If you are taking 'short-cuts', then I can't be held responsible for it not behaving itself...


Mike.

I use LAUNCH script to run this prompt

Thanks Reply

[watchdog]

G'day Mike W.,

I'm trying your 64-bit Chrome Portable, which runs, but I cannot import my html file of bookmarks.

In a similar situation I used another working puppy to import bookmarks in the portable profile which were retained in the original not working puppy. I do not remember which puppies they were.

[mikeslr]

It's late and I don't have Google-Chrome running on this Puppy. But my recollection is that Google-Chrome 'runs-as-spot' and includes a permission changer on its menu (under Filesystems).

If so, in order to import bookmarks you first have to export them as an html; either from a different Puppy or a different web-browser. Then copy them to the /home/spot/uploads folder. Use the permission changer to change permissions from root to spot. Google-Chrome will then be able to import them.

[Tip: In the future, frequently export bookmarks using the opportunity to give them informative names and dates. Save them in a folder. Periodically prune the older versions].

[Mike Walsh]

@ David:-

I'm trying your 64-bit Chrome Portable, which runs, but I cannot import my html file of bookmarks.
Chrome seems to do the Import but when I then try to set up the 'imported' bookmarks, they are not there. Just the three default Google bookmarks.

Mm. I have had this issue with some of the Chromium-based browsers at times.

At one point, a few years ago, I was using your method to link a single, external version of many apps into multiple Puppies.....mainly browsers. In recent years, I've been using many more remotely-situated AppImages, which just need a Menu-entry + a sym-link for .config directories. In recent months, I've pretty much abandoned the older way of 'sharing' stuff, because my browsers are now all self-contained 'portable' versions, and together with the multitude of AppImages I have for various things makes setting up a Puppy an absolute cinch.

Added to which, I'm no longer running the vast number of different Pups I used to with the old Compaq tower, since this new HP tower has issues with attempting to boot those older Pups.....it's pure UEFI. Currently, all I'm running is Bionicpup64, radky's DPup 'Stretch', and a fully-functional, recently-installed version of ChromiumOS running from a 64 GB SanDisk USB 3.0 flash-drive - in which, with this new, up-to-date hardware, absolutely everything works, auto-connects, auto-sets up, etc, etc. The damn thing boots in around 5 seconds; it's insanely fast, and works for me since I spend much of my time on-line anyway. A Chromebook would suit me down to the ground, but one pricey piece of new hardware is quite enough for me.....and this way, I can "use" a 'Chromebook' without needing to actually buy one!

Because space is no longer an issue for me - I have somewhere approaching 5 TB of the stuff! - I've returned to using the 'Sync' feature between my various Chromium-based browsers, so importing bookmarks is no longer required. Bookmarks, extensions, apps, everything, is automatically synchronised between all browsers as soon as they fire-up. I've got to the stage where I'd sooner make life as easy as I can for myself.....

I know, I know; I'm "letting the side down", aren't I?

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

There is one way you might be able to do this, although it'll only work between Chromium 'clones', AFAIK. If you go into the 'profile' of any 'clone', then into 'Default', you'll find a plain-text file simply called 'Bookmarks'. The latter half of this is usually a single, enormously long line of coded 'metadata', but that's not relevant here. Point is, it contains all your bookmarks info in the format in which the browser uses them.

I've not yet tried this, but I suspect you could simply copy this file across, followed by a re-start of the browser, and your bookmarks ought to show. It's worth a try with a test 'copy' of the browser in a different 'work' location; because these portables are self-contained, one instance won't interfere with another. You'll need to fire it up once before trying this, so the 'PROFILE' directory gets created.

If you decide to try this, let me know how you get on, would you? I'd be interested to know what happens, like....

[EDIT:-] Just confirmed this works. I was having real issues getting my bookmarks into the 'portable' I've just built of the Yandex browser, so I thought I'd give this a whirl.

Stuck a copy in my main 'WORK' directory - a big area I keep specifically for any kind of 'development' work - fired it up and let it create the 'PROFILE' directory. Closed it down. Copied the afore-mentioned 'Bookmarks' file from Chrome's 'PROFILE'->Default across to the same location in Yandex; 'PROFILE'->Default->Bookmarks.

Fired the browser up again, annnd.....bingo. There they all were.


Mike.

[davids45]

G'day,
Thanks for the various suggestions but nothing I did fixed the absence of imported bookmarks.
Oddly, deleting the bookmarks text file in the Default directory did not remove the few bookmarks of mine I added the 'normal' way (visit the site and click on the star icon).

Mike W's suggestion about copying the bookmarks textfile from another Chrome browser did not work but when I opened the other browser with Chrome-Portable also opened, I dragged the bookmarks from the 'other Chrome' bar to the Chrome-Portable and these worked.
When I dragged the 'Imported bookmarks' bar button (produced by importing successfully an html file into that browser), all the bookmarks now were available in Chrome-Portable.
Checked by opening a different 64Pup then Chrome-Portable running from the data partition.

This 'fix' works if you have another Chrome browser that will import html files and in doing so, adds an 'Imported bookmarks' button to its Bookmarks Bar.

I haven't tried with a non-Chrome browser.

Passwords are not imported with these Bookmarks so there's still some work to do.

David S.

[davids45]

G'day,

Playing with several Portable Browsers (Chrome, Brave, Opera, Vivaldi) in a range of Pups (Bionic & ScPup), I'm finding when I try to download a file, the browser disappears/crashes (no message pops up). I haven't yet tried this starting from the terminal.

Usually, it's the latest cryptic crossword as a pdf from the Guardian site if that matters - I then download it via a non-Portable browser.
This disappearance is repeatable when I've tried reloading the same browser to download the same pdf.

Could it be Spot related?

Opera is sometimes unwilling to start, but otherwise, browsing has been all good with the Portables.

David S.

[Mike Walsh]

@ David:-

Nah, that's an easy one, that is. I can tell you straight you straight away what the issue there will be; /usr/share/glib-2.0/schemas will be missing the

org.gtk.Settings.FileChooser.gschema.xml

....file. This is what allows downloads to take place.

It was a built-in component of the older SFS packages I used to build, but these 'portables' don't contain it. However, I ran up a .pet package for this function, because Mikeslr found he was getting the same issues in one of Fred's Quantum-portable packages. (I think that was the one.) It was attached to the bottom of a post in that particular thread, but I can't find it now, so I'll re-attach it here.

All it does is to supply half-a-dozen or so of the most commonly-needed 'schema'.xml files, along with re-running the

Code: Select all

glib-compile-schemas

.....command at each boot. It's only around 3 kb in size, but it apparently fixes this browser crash issue for quite a few mainstream browsers, too.

Just install the attached .pet, then re-start your browser. It should cure the problem. Original inspiration for this 'fix' came from peebee/OscarTalks.

EDIT:- Exec script for .pet modified according to the following post from Fred, and .pet re-attached. Cheers, mate.


Mike.

[fredx181]

All it does is to supply half-a-dozen or so of the most commonly-needed 'schema'.xml files, along with re-running the

Code:
glib-compile-schemas

Anyone correct me if I'm wrong, but I think glib-compile-schemas needs to point to the /usr/share/glib-2.0/schemas directory, so then:

Code: Select all

glib-compile-schemas /usr/share/glib-2.0/schemas

Also, glib-compile-schemas may not be in PATH, so the safest would be to use:

Code: Select all

/usr/lib/glib-2.0/glib-compile-schemas /usr/share/glib-2.0/schemas

Fred

[Mike Walsh]

@ Fred:-

Sorry, that was abbreviated for the post, mate..! The wee script in /usr/sbin that runs it (sym-linked into /root/Startup) reads:-

Code: Select all

#!/bin/sh
#
glib-compile-schemas /usr/share/glib-2.0/schemas

It's always worked for me. I double-checked this with OscarTalks' before I implemented it, and cross-checked it with the way peebee puts it into his Chromium 'wrapper-script'.....both agreed.

I don't know about the 'Dogs', but the 'buntu-based Puppies always seem to find it.....although the point about the $PATH is well-taken. I can soon edit the script to do it that way; it certainly couldn't hurt, and would merely confirm an absolute path to be used rather than relying on the system variables/$PATHs.

Good catch. Cheers.

EDIT:- Pet modified, and re-attached to earlier post. That's actually how I prefer to do things myself; I know the whole idea of the default $PATH variables is so that you don't need to type out paths in full every time.....but I know I can trust an 'absolute' path. Every time.


Mike.

[davids45]

G'day Mike & Fred,

Thanks for offering the fix for my Guardian crossword addiction.

Still being an Ignoscenti, does this .pet fix the Pup or the Portable? I suspect it's the Pup, so each 64bit Pup on my computers needs this ?

Could I make an sfs from the .pet and combine this sfs with my all-apps-links sfs that I have already shared to each 64Pup? This would automatically provide the fix to every 64bit Pup, ....if I get it right .

I've done a quick check of the pet and Brave seemed to be OK to download yesterday's cryptic. But as I already have that cryptic, I'll do the real test later today when the Guardian catches up with us here on Oz leading the world into tomorrow (well, 9-11 hours ahead of GMT depending on the season).

(edit) I see there's a linked executable in Startup which could need to run before the sfs is loaded?

Thanks as always,

David S.

[Mike Walsh]

@ David:-

(edit) I see there's a linked executable in Startup which could need to run before the sfs is loaded?

Um; well, an executable script, yes.....not a binary, obviously; this whole thing is nothing but a bunch of scripts. But no, there's no reason why you couldn't combine this into your "all-Pups" thing; it's only got to be present on each system to stop browsers crashing. AFAIK all modern browsers will need something like this for file-transfers to occur correctly.

It will work for all versions of Chrome, 'portable' or otherwise. It also works for every Chromium-based 'clone' out there, plus the Mozilla-based browsers, too. It's nothing to do with the format, layout, packaging or otherwise of each browser; AFAIK it's to do with the way in which the transfer mechanism functions. And with the way in which the WWW works, with all its various protocols, that HAS to be pretty well standardized, no?


Mike.

[davids45]

G'day Mike W.

Thanks for replying.

Your earlier post with the .pet enabled me to find my actual problem with some portables disappearing when trying a download. As normal, it was me .

For my first Portable, I'd set up (absolute) links to the Opera files on my data partition.... then absent-mindedly moved the originals so the links became 'file not found' (exclamation mark yellow icons). Subsequent portables then couldn't use the lost-links and their good links did not over-ride the dead ones.

Checking the schema directories revealed all.

I've now fixed my problem and everything is running as expected (Iron, Brave, Google-Chrome, Vivaldi Portables). Bionics and ScPups happy.

I am now creating links-only sfs for the Portables (and Wine and LibreOffice AppImages if I can) and will then combine these with my existing all-apps-links sfs so I just have one sfs to mount for any Pup.

That's my theory, anyway .

By the way, I am seeing a browser start-up message about an 'unsupported' '--no-sandbox' line in the Portables. 'Stability and security will suffer'. I assume this is to be ignored - sounds like something just for Windows users?

David S.

[Mike Walsh]

@ David:-

That 'infobar' about using the '--no-sandbox' "switch" I normally only see on the Iron portables. It may occasionally show up in Chrome itself, and I can't remember whether I've seen it in Brave or not.....I only used that one briefly when I first built it. I'm not terribly keen on Brave, but as you know, my motto has always been 'Choice in all things' where Puppy's concerned (which is why I've built so many different browser packages recently). It's to do with the individual sandboxing process per tab used by these browsers, and also to do with the whole 'run-as-root' business here in Puppyland. Which Big Brother frowns mightily upon....!!

It showed up on 'first run' in Yandex, but the Russian devs have set things up so you can prevent that from repeatedly showing by ticking a check-box somewhere in the maze of its settings.....

Anyway; glad to hear you're 'sorted'. There's always going to be glitches of one sort or another with these browsers, though I believe it's a tribute to the robustness of the coding and the soundness of the basic design that we don't get more than we do.....


Mike.

[Mike Walsh]

Okay, guys'n'gals. Here's the new Chrome 81 'portable' - 81.0.4044.92.

Same instructions as always. Download it; unzip it. Put it anywhere you like. Click to open, click 'LAUNCH' to fire it up.

Easy-peasy.

Download location as in post #1.

Checksums:-

MD5 - 6566a4f7fbe8c2f7281f7a4d1627cbec

Sha256 - a1c7e0a8aca234b3b8da12ff8f4a03d3dc04df31ac751ceaff94fd2682923d20

Any issues, you know where I am. Enjoy.


Mike.

[Mike Walsh]

Hi, all.

Google_Chrome-portable 83.0.4103.61 is now available for download. Location link as in post #1.

Usual procedure; download, unzip, place it anywhere you want; click to open, click "LAUNCH" to fire up. Simples.

MD5 - 8c2ad1d4191e53f40833080281bb3db4

Enjoy. Any 'issues', you know where to find me.


Mike.

[davids45]

G'day Mike W.,

I am seeing a lib version problem in this Google-Chrome in alpha-beta FossaPup64 where LAUNCH is trying to use the (newer?) file in Fossa64 ('4400' in file name) , not the (older?) file in the lib directory of Google_Chrome-portable ('4000').

Google_Chrome did not run in Fossa64 initially whereas it did in Bionic64 Pups.
A Fossa64 terminal run shows a problem with libpangoft2-1.0.so.0 which is a link to a longer titled version of this lib file. In Fossa, it's "...4400...", in the portable's lib directory it's "...4000..."

If I switch the older lib file into Fossa64, Google_Chrome works but lots of stuff in Fossa then doesn't . Poweroff needed and a Savefile backup fix.

Opera-portable also worked with the lib switched Fossa64 when before it hadn't in Fossa64.

Both Opera-portable and Google-Chrome-portable have the '4000' version in their lib directories but these are not being found first so the problematic version in /usr/lib/... in Fossa64 stops the browsers running?

I haven't tried switching the 4400 version into the portables in place of their 4000 versions so that could be a fix?

Maybe it's a glitsch in this early version of Fossa64, or something in the things I added to FossaPup64, but your advice would be welcome.

David S.

[Mike Walsh]

@ David:-

Just for the hell of it, switch the '4400' version into portable-Chrome's 'lib' directory and let me know what happens, would you?

Chrome has always been a 'moving target' in Puppy, in addition to being a major PITA, and although battleshooter helped me out enormously by figuring out the necessary libs a few years back, I knew they wouldn't last for ever. Possibly time to upgrade the contents of the 'lib' directory; the next ones I foresee issues with will undoubtedly be the NSS libraries. Again.

(When those get 'out-of-date', the 'clones' stamp their little feet, pout, and point-blank refuse to 'play nice'...)


Mike.