Puppy Linux Discussion Forum

@mikewalsh I'll do a fresh download and have another go at it with a pristine fossapup64 when I have a bit of time. In the short run, doesn't matter much as version 91 runs fine. In the longer run it's well worth sorting. I quite like Un-Googled. Thanks for supporting it

mikewalsh wrote: Thu Feb 04, 2021 1:38 pm

Bottom line; Xenialpup64 is too old to run UnGoogled Chromium. UGC requires a minimum glibc of 2.29; Xenialpup64 uses 2.23. That's why it won't run...

Very non-personally, my question becomes: Why does anyone need Chromium 92 right now?
What are you doing in Chromium 92 that you couldn't in.... (arbitrary) 87?
Which security threat are you less afraid of?

Chromium in 32 Xenial is 62 default. As of today the repository version is 90.

Starting to grasp how this works as a person who doesn't write code, despite working in other distributions, every portable and .sfs browser should have the name of the distro it was made for in its name, because that's how tailored they are.

writes the user running Chromium 65 in Xenial with tahr dependencies

Inch by inch. I now have the v92 running in my minimized Fossapup64, both stock stock, and using my shared profile. On first run, the LAUNCH or LAUNCH_NL scripts create a directory PROFILE in the Ungoogled_Chromium-portable directory and symlink it from within the spotted chromium subdirectory. As created that PROFILE directory has root:root permissions and chromium can't set a singleton or lock file for me.

root# ./LAUNCH_NL
[10081:10097:0821/130203.403642:ERROR:disk_cache.cc(184)] Unable to create cache
[10081:10097:0821/130203.403794:ERROR:shader_disk_cache.cc(606)] Shader Cache Creation failed: -2
[10081:10081:0821/130203.421776:ERROR:process_singleton_posix.cc(281)] Failed to create /mnt/sda2/ungoogled_chromium/Ungoogled_Chromium-portable/PROFILE/SingletonLock: Permission denied (13)
[10081:10081:0821/130203.421889:ERROR:chrome_browser_main.cc(1292)] Failed to create a ProcessSingleton for your profile directory. This means that running multiple instances would start multiple browser processes rather than opening a new window in the existing process. Aborting now to avoid profile corruption.

I added

chown -R spot:spot "$HERE/PROFILE"

as line 8 in both LAUNCH scripts, following the creation of PROFILE and the beast now sets the singleton and lock files and runs. Posting from it now.

Still getting the trace break error in my LxPupSc64 install. Tried the Fossapup64 version of run-as-spot (older) but not that. In the process I did update the extra libraries I add for the LxPup to what is in FossaPup64 (newer than what I was using) and now in FossaPup LAUNCH and LAUNCH_NL work interchangeably as expected. I'll pick away at the LxPupSc64 but a lower priority there as in that I usually use SlimJet whereas in the non-save-file FossaPup64 the Un-Googled is the sole browser.

@Marv :-

Mm-hm. OK. Yah, thanks for the heads-up.

I've failed to do what I've done with Chrome. It, too, has to run as spot, but I've chowned the 'PROFILE' directory at both ends of the sym-link there for a long time. I hadn't realised I'd failed to do that here.

It doesn't affect my personal 'browsers' directory, from where I run all my portable browsers. I've had scripts in place for quite some time now; at upgrade time, they automatically swap things over from old to new, along with re-symlinking & resetting ownerships/permissions in all the appropriate places.....all set in motion by a single click.

Makes me lazy!!

Mike.

I am running v92.0.4515.131 from /opt folder in xenialpup64 75 frugal install.
Upon running "Ungoogled_Chromium.sh" it runs but with 2 warnings (at start & end).

root# ./Ungoogled_Chromium.sh
ln: failed to create symbolic link '/opt/Ungoogled_Chromium-portable/chromium/PROFILE/PROFILE': File exists
[16009:16009:0919/150734.331444:ERROR:browser_dm_token_storage_linux.cc(94)] Error: /etc/machine-id contains 0 characters (32 were expected).
[16009:16064:0919/150734.349092:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[16009:16064:0919/150734.349149:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[16009:16064:0919/150734.393441:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[16009:16064:0919/150734.393513:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[16009:16029:0919/150735.708416:ERROR:ev_root_ca_metadata.cc(841)] Failed to register OID: 0
rm: cannot remove '/opt/Ungoogled_Chromium-portable/chromium/PROFILE': Is a directory

Although it is running, whether there's any config mismatch causing these warnings?
Thanks.

@vin :-

Two things.

• One; you're obviously not running my portable version, because it doesn't use a script called "Ungoogled_Chromium.sh". Where did you get this browser from, please?

• Two; as for all the terminal output, this is nowt to worry about with Chromium-based browsers. When Google first set up the Chromium Projects back in 2008, one decision they took was that the browser should give what amounts to an ongoing, real-time debug report in the terminal, all the time it's active & running. This helps developers to spot problems quickly, but it scares the bejesus out of ordinary "mortals" who aren't aware of this...

If they ever spot any of this stuff, they're convinced the thing is going horribly wrong!

Mike.

mikewalsh wrote: Sun Sep 19, 2021 10:48 am

@vin :-

Two things.

• One; you're obviously not running my portable version, because it doesn't use a script called "Ungoogled_Chromium.sh". Where did you get this browser from, please?

This is your very own browser
I have added "Ungoogled_Chromium.sh" in it, which contains this code --->

cd /opt/Ungoogled_Chromium-portable
./LAUNCH_NL

Ultimately it runs LAUNCH_NL

• Two; as for all the terminal output, this is nowt to worry about with Chromium-based browsers. When Google first set up the Chromium Projects back in 2008, one decision they took was that the browser should give what amounts to an ongoing, real-time debug report in the terminal, all the time it's active & running. This helps developers to spot problems quickly, but it scares the bejesus out of ordinary "mortals" who aren't aware of this...

If they ever spot any of this stuff, they're convinced the thing is going horribly wrong!
Mike.

You are right that chromium spits out volumes of debug messages.
But the warnings on first and last line were not there earlier.
I had shifted the xenial save folder inside another folder.
After that, these warnings are shown.
Does it have anything to do with shifting save folder? (I don't see any reason)
Thanks.

@vin :-

Ah. Okayyy.....

Moving the save-folder inside another directory would only affect things if the browser was running from outside the save, but from the look of things you're running it inside the 'save'..? I'm not entirely clear on how you ARE running it.

It looks like you've modified it further? It should work fine as published...

The other bit I don't understand is that first line. How did you end up with a directory inside /chromium called 'PROFILE', which then has another 'PROFILE' inside of THAT? The launcher is coded to look for

--user-data-dir=$HERE/chromium/PROFILE

...NOT:-

--user-data-dir=$HERE/chromium/PROFILE/PROFILE

I can't figure out how you ended up with a second-level nested 'PROFILE' inside another one.....

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

That last line is now there because it's expecting to find a sym-link, but is encountering a directory instead; the command-line removal of a directory is slightly different to that of a sym-link, y'see.

Mike.

Edit: OOPS, I read vin as Mar vin Too much coffee, too little shuteye. Anyway, the post is how I run ungoogled so I'll leave it...

@mikewalsh
Dunno about the PROFILES, but I always unpack/run outside the save. When I tested 92, both in my minimum FossaPup64 and in the 64b Slackware derivs, I first downloaded, extracted into a directory named ungoogled_chromium on my /dev/sda2 EXT2 data directory and ran (from terminal) LAUNCH_NL in the created Ungoogled_Chromium-portable directory.

A directory named PROFILE is created, not inside /mnt/sda2/ungoogled_chromium/Ungoogled_Chromium-portable/chromium but in /mnt/sda2/ungoogled_chromium/Ungoogled_Chromium-portable. It had root root privileges as created, so 92 wouldn't run. Changing them to spot, nothing else done, got 92 working in the FossaPup64 install. Thus the chown line I added to the scripts and reported on earlier.

Once working, I do move it and run it in my Browser_Source directory on my data partition (never in save) and usually modify scripts so the PROFILE is in a common spot dir in that data directory shared across all pups and ungoogled versions. That bodging is mine and I tweak it til it works and never report on that since it's not how you package it, but my initial run/no run tests are all with a straight download and extract. I haven't done that PROFILE swap bodge yet with 92, its' PROFILE remains exactly as created above except for the priv changes.

All the pups had had 91 installed and working prior to testing 92 though with the portable structure I can't see how that should matter.

Posting from: Version 92.0.4515.131 in my ydrv driven savefile-less FossaPup64 install.

@Marv

Marv wrote: Sun Sep 19, 2021 11:43 pm

A directory named PROFILE is created, not inside /mnt/sda2/ungoogled_chromium/Ungoogled_Chromium-portable/chromium but in /mnt/sda2/ungoogled_chromium/Ungoogled_Chromium-portable.

I am unaware how 2 PROFILE folders got created. One inside /mnt/sda2/ungoogled_chromium/Ungoogled_Chromium-portable/chromium
and another in /mnt/sda2/ungoogled_chromium/Ungoogled_Chromium-portable.

@mikewalsh
I have removed the messed-up Un-Googled folder and did it right from scratch.
Now it is in /root/spot
Faced no issue now.
Working ok.

Thanks for sharing your time & inputs.

@vin/@Marv :-

The way I've built it is thus; there should not BE a 'PROFILE' directory inside /chromium unless the browser is running. The actual 'PROFILE' sits at the top level; it's sym-linked within the /chromium directory prior to launching the browser; at close, the sym-link is then removed again.

I only did it this way to try and make things a bit simpler for those wishing to use an existing profile. If individuals then wish to modify the package further, I can't be held responsible!

Possibly over-complicated? Maybe it would be simpler just to revert to creating the PROFILE within the browser directory.....and leave it at that? What do y'all think?

Mike.

mikewalsh wrote: Mon Sep 20, 2021 9:39 am

@vin/@Marv :-

The way I've built it is thus; there should not BE a 'PROFILE' directory inside /chromium unless the browser is running. The actual 'PROFILE' sits at the top level; it's sym-linked within the /chromium directory prior to launching the browser; at close, the sym-link is then removed again.

I only did it this way to try and make things a bit simpler for those wishing to use an existing profile. If individuals then wish to modify the package further, I can't be held responsible!

Possibly over-complicated? Maybe it would be simpler just to revert to creating the PROFILE within the browser directory.....and leave it at that? What do y'all think?

Mike.

I like having the 'PROFILE' directory top level. It does indeed make it simpler IMO and I like the libs&program/data separation. Pretty simple also when I do modify it to point at my version-shared 'PROFILE'.

mikewalsh wrote: Mon Sep 20, 2021 9:39 am

@vin/@Marv :-
Possibly over-complicated? Maybe it would be simpler just to revert to creating the PROFILE within the browser directory.....and leave it at that? What do y'all think?
Mike.

I don't think it is overly complicated.
In fact, the way you have structured it makes sense.

Has anybody experienced crashing of tabs in either v92.0.4515.131 or v90 ?
In my xenialpup64 7.5, many times crash is experienced on both the versions. Only new tabs crash upon opening. Existing tabs keep working.
In Lubuntu on same m/c, it's not seen.

vin wrote: Sat Sep 25, 2021 2:34 pm

Has anybody experienced crashing of tabs in either v92.0.4515.131 or v90 ?
In my xenialpup64 7.5, many times crash is experienced on both the versions. Only new tabs crash upon opening. Existing tabs keep working.
In Lubuntu on same m/c, it's not seen.

No crashes at all here in v90,v91, or v92.0.4515.131. Absolutely rock solid, but I only run them in fossapup64 9.5 (a minimized savefile-less install) or LxPupSc64 21.04 +3 (various kernels, v90 and v91 only) on the i5 based laptops circa 2012. I would estimate ungoogled gets about 30% of my browsing use with the current SlimJet from SFS the balance. I seldom have more than 3 tabs opened but I just tested v92 with 10 and it was ok. Slimjet doesn't play youtubes at this time but ungoogled does flawlessly so...

Google search yields some suggestions---

1) it might be due to extension installed.
>> I have installed Ad Block & duckduckGo extensions.
After crash, tried pausing the extensions. No success.
But those are there in Lubuntu either! There the issue is not experienced.

2) Open Incognito & see.
>> Crashes in Incognito.

3) clear cache & cookies.
>> After crash, "chrome://settings/" also does not work. New tab crashes.

Marv wrote: Sat Sep 25, 2021 2:50 pm

No crashes at all here in v90,v91, or v92.0.4515.131. Absolutely rock solid, but I only run them in fossapup64 9.5 (a minimized savefile-less install) or LxPupSc64 21.04 +3 (various kernels, v90 and v91 only) on the i5 based laptops circa 2012. I would estimate ungoogled gets about 30% of my browsing use with the current SlimJet from SFS the balance. I seldom have more than 3 tabs opened but I just tested v92 with 10 and it was ok. Slimjet doesn't play youtubes at this time but ungoogled does flawlessly so...

@Marv :-

What's happening when you DO try to play YouTube vids with Slimmie ATM? (I have to ask; I assume you take Flashpeak's advice vis-a-vis where to get the upgraded variant of libffmpeg.so from, yes?)

https://www.slimjet.com/en/libffmpeg.php

I confess, it's not giving me any problems here in the portable version. I'm surprised that yours IS.....

Mike.

mikewalsh wrote: Sat Sep 25, 2021 10:03 pm

@Marv :-

What's happening when you DO try to play YouTube vids with Slimmie ATM? (I have to ask; I assume you take Flashpeak's advice vis-a-vis where to get the upgraded variant of libffmpeg.so from, yes?)

https://www.slimjet.com/en/libffmpeg.php

I confess, it's not giving me any problems here in the portable version. I'm surprised that yours IS.....

Mike.

For the last 3 or 4 SFS run-as-spot versions of Slimmie (from memory) trying to play any youtube results in a nag about my audio renderer and a black youtube screen, no crash. Same behavior in LxPupSc64 and fossapup64. All of these are run-as-spot from SFS and rock solid in every other way. Yep, I always have the latest libffmpeg.so on board per slimjets instructions. Hardware is the i5 based all intel Fujitsu S761 laptop circa 2012 and sound works perfectly otherwise. Clean dmesg.

In the 64b Slimjet version 32.0.1.0, just set up, run from SFS as I usually set them up from the stock Slimjet download, there is some change. Checked in LxPupSc64. No longer has the audio nag, but just a 'time circle' in a black screen. The thumbnail videos now are animated.

I havent tried your portable, I will and report back. Just thought, I haven't checked 32b Slimmie in one of my 32b pups. Just set up that v32 SFS also so I'll try it too.

Since ungoogled works so well it really hasn't been worth chasing, just noting.

Update: OK, your 64b v31 portable is fine in both fossapup64 and LxPupSc64, sound and all, but just not spotted. My SFS v32 run-as-spot is also ok in fossapup64 but not in the slackware derivs. There I get the following message in the 32b, just a spinning circle in black in the 64b:

I'll probably chase that as a lib problem in a bit using your portable as a guide.

Thanks,

Evening, gang.

Right. Now then; apologies for the gap between this new release and the previous one, but I've got so many packages on the go it's easy to lose track of things.....and the older ya get, the worse it becomes! Anyways....

'Marmaduke' released this version about 11 days ago, and it was only a single 'point' release behind at that time - probably 3 by now, but who's counting? So, for your perusal, here's the Puppy-portable package of v94.0.4606.71.

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

This portable version now has the 'Menu add/remove' scripts included. Also, since Marmaduke compiles these with full VAAPI support, I've added the "--enable-features=VaapiVideoDecoder" switch in both wrapper scripts. If I understand him correctly, enabling this will permit proper deployment of hardware graphic acceleration via your GPU.....the more so if you're running a discrete card. (For anyone who hasn't come across these multiple 'LAUNCH' scripts before, read the 'LaunchReadMe' file.....all will become clear.)

You can check hardware acceleration status from entering

chrome://gpu

.....in the URL bar.

WideVine also comes supplied by default, so NetFlix, Hulu, Spotify et al will run OOTB.

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

Realistically, since Marmaduke appears to have now updated his build-environment - and we've finally reached that point where the code-base now wants newer GTK-3.0 stuff AND a load of other, newer stuff - I would say these are probably limited to Bionicpup64 onwards as things stand ATM. Especially given that I've reached the limit of being able to keep these working for older Puppies. It's time to move on, guys; sorry an' all that!

Anywhere from Xenialpup64 backwards is a 'no-go' from now on.....everyone is building for 5-series kernels and at least glibc 2.29/2.30 and up.

You can find the new version at the usual link in post #1. Have fun with it. I do..!

Posting from it in Fossapup64 ATM.

Mike.

Thanks Mike, the v94 Un-Googled Chromium portable runs OOTB in the fossapup64 9.5 install on the intel i5 based Fujitsu laptops.

Still no go with the slackware LxPupSc64 21.04 +3 install on that hardware. All libs ok if libpng12 added but I haven't unravelled the issue with run-as-spot and un-googled. It remains as I posted above for v92. v91 is fine. Since the v92 based Slimjet 32.0.2.0 runs fine in that slackware deriv when run-as-spot and your spotted v94 based un-googled portable is fine in fossapup64, it seems to me like an un-googled/run-as-spot conflict in the LxPup64. Haven't gotten any farther than that as yet.

I noticed that in version 95.0.4638.54 there is a new feature in Graphics Feature Status (chrome://gpu/)
Canvas out-of-process rasterization (the rasterization of 2d canvas contents is performed in the GPU process).
It is turned off by default, but turns on easily. chrome://flags/ in the address bar. Then we enter the word Canvas into the search and look for the Out-of-process 2D canvas rasterization item. Change Default to Enabled and restart.

If you go to chrome://gpu/ in the new version (96.0.4664.45), you can see the new Raw Draw function. You can enable it in chrome://flags/

A bit of boring theory. The Raw Draw function will reduce the load on system resources by changing the principles of rendering the necessary parts of the page. In the process of rasterization, Chrome (or who he is disguised as today ) uses a grid of cells with a size of 256×256 pixels. Resources are distributed between different cells, thanks to this, Chrome does not need to "recalculate" and redraw the entire page every time the user interacts with it. Boooring !

Yes, overall not bad. But on some sites (for example https://zen.yandex.ru, but certainly on others too), pages and comments are displayed incorrectly and cannot be read.

So I have enabled this feature... and after a while turned it off.

Afternoon, gang.

Right; it's 'upgrade' time again. 'Marmaduke' has just released his newest build, now of the '96-series' - v96.0.4664.45.

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

No obvious changes to report; everything is still running as smooth as so much oiled silk, which I've come to expect from Marmaduke. Widevine fully functional as always, and the compiled-in VAAPI video-decoding all present & correct.....which allows Chromium to offload video decoding onto your GPU. Nice one, mate!

You will notice one small change I've added. Marv contributed his snippet of code for the tail-end of the wrapper-script, which will tell Chromium to delete the contents of /PROFILE/Default/Cache.....because Ungoogled Chromium can't clear its own cache files without instruction.

rm -rf $HERE/PROFILE/Default/Cache/*

I've incorporated this into a wee GUI that pops-up at close, which asks the user if they wish to clear the contents of the cache, and gives them the option to do so (or not, as the case might be).

(For those of us who know what we're doing, yes; it's but a moment's work to go into the wrapper-script & make the appropriate changes. But for newbies, I feel a GUI will make things just a wee bit more "user-friendly" for them, that's all.)

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

You can, as usual, find this at the download URL in post #1. Usage as always; d/l; unzip; place the portable directory anywhere you want.....preferably, outside the 'save'. Click to enter, click the 'LAUNCH' script to fire it up. The 'PROFILE' directory is created at the top level.

Posting from it now. Enjoy.

Mike.

Grey wrote: Sun Nov 21, 2021 10:21 am

pages and comments are displayed incorrectly and cannot be read.

Interesting. Such an unpleasant effect manifests itself if I run the Marmaduke version. However, if I run the version from Arch using Conty (not Marmaduke, but ungoogled), then everything is fine. I don't know why yet.

It's strange, because the Raw Draw function in all versions should have been "stolen" from Chrome

v96 runs OOTB on my minimized fossapup64 9.5 install. Also runs fine using my shared profile. Using it as the main browser there now. Still no luck in the slackware based LxPupSc64 21.04 +4. Adding libpng.so.0.54.0 and libpng12.so.0 (symlink to libpng12.so.0.54.0) to your top level lib and tweaking the LAUNCH script to find LxPupSc64 as well as tahr gets it launching with no lib nags but it still gives:

./LAUNCH: line 18: 21566 Trace/breakpoint trap   run-as-spot "$HERE/chromium/chrome" --enable-features=VaapiVideoDecoder --user-data-dir=$HERE/PROFILE --disable-infobars "$@"

The last un-googled version that didn't do that was v91.x.x.x. I'll fiddle with disabling features a bit later but had no luck in v92 and v94.

Thanks,

'Kay, gang. Update time again.

Here's the recent release - from Marmaduke - of v96.0.4664.93. This brings us bang up-to-date on par with Chrome, so the new Puppy-portable version is now available for download from the usual link in post #1.

Nothing to report; everything still working beautifully, so.....enjoy!

Mike.

Got it. Thanks. Runs perfectly in my minimized fossapup64 9.5 both OOTB and with the launcher modified to use my 'shared' profile. Added in the libs and test for LxPupSc64 per my post above but haven't tried it yet there.

Cheers!

Sorry, guys. Another update has hit the tubes, and puts Ungoogled Chromium back on "par" with Chrome again. Here's the Puppy-portable package of v96.0.4664.110.

Nothing new to report, so.....enjoy. DRM working sweetly as usual, thanks to the included WideVine. You can find the download link in post #1.

As always.....d/l; unzip; place anywhere you like - outside the 'save' is best. Click to enter, click 'LAUNCH' to fire it up.

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

Thanks to those who've helped with the development of these portables over the years. Y'all know who you are.

Mike.

No worries here, Updating is pretty painless really.

Downloaded and extracted. Runs OOTB in my minimized fossapup64. Swap in my launcher to share the profile and point the .desktop to it and good to go there also in fossapup64.

I add libpng12 to the top level lib for the slackware derivs but still no go in them. Same Trace breakpoint error as with 92,94, and earlier 96 versions of un-googled all run-as-spot. Less of an issue in those derivs now since SlimJet 32.0.4.0 fixed the problem with youtubes OOTB in fossapup64 and with a little alsa-apulse hokey pokey also in the slackware derivs, both run-as-spot.

Cheers,

Right, gang. It's update time again.

Marmaduke released his newest build approximately a week ago, so here's the Puppy-portable version of v97.0.4692.71.....back level with Chrome again.

Nowt to report; smooth as ever, with all the usual integrated bits'n'bobs......along with Marv's 'cache-clear' command, built into a wee GUI that pops up at close.

You'll find it at the usual link in post #1. D/l; unzip; move the portable directory where you want (preferably outside the 'save'). Click to enter, click 'LAUNCH' to fire it up. Scripts will let you add a MenuEntry if so desired.

Enjoy!

Mike.