After nearly two weeks of pulling my hair out I finally was able to build the newest Chromium in its un-Googled variant. You can find packages for Slackware 14.2 and -current in my repository on slackware.nl.
It’s a jump from the 92 to the 94 release (94.0.4606.81 to be precise) but I simply did not have the opportunity to build a 93 release. In part because the un-googled repository maintained by Eloston did not offer release tarballs for a while. Extended leave of absence of the maintainer seems to be the issue which by now has been resolved by giving more people commit access to that repository.
The un-Googled version of Chromium is incapable of “phoning home” to Google, by altering the source code and stripping/mangling all occurrences where that might happen. This is basically what Eloston’s project does.
It’s still the powerful Chromium browser engine but then without the privacy concerns that surround Google’s Chrome browser and to a lesser extent also its Chromium open source variant.
Read my earlier article “How to un-google your Chromium browser experience” to learn more about my reasons for providing the package as well as pointers to make it a pleasant browser experience.
Back to my first sentence of this blog post. I started building one of the earlier 94.x source releases of Chromium (to create the actual chromium, not the chromium-ungoogled package). It took some work to get it to compile without errors – an annoyance which always occurs when switching to a new major source release. But it produced a package.
It did not take long to discover that in Chromium 94, finally my Google client-id stopped working, meaning a loss of access to my Google Cloud-synced data. Well OK, I was waiting for that to happen since March of this year so no real surprise there.
What did take me by surprise is what happened when I switched to a different Google client-id; one that does have access to Google Cloud sync. Unlike with pre-94 releases where I performed the same tests, enabling Google Cloud-sync makes the browser crash every time I start it after it has completed its initial full sync (making all my bookmarks, passwords and browser history available locally). I have not found a way to fix this crash behavior, and decided to forestall a package upgrade in my repository until I am certain that it can be fixed at all – or not.
Note that configuring Chromium to use a different Google Client-ID is not hard to do – but I leave it as an exercise for the reader to find out how exactly this is done.
After this debacle with Chromium 94 I decided to instead build a package for chromium-ungoogled since that variant is incapable of syncing data to/from Google anyway and I wanted a working browser.
That effort took me almost 10 days… ten frustrating days. A compile of the Chromium sources takes roughly 8 hours on my hardware and the issue would typically occur on the very last of 50,000 compilation steps: linking the final chromium binary! It would fail to link on 32bit Slackware with a “LLVM error: out of memory“.
Eventually (not many people produce 32bit builds of Chromium anymore) it seems that this is an issue with the custom llvm-12.0.1 which I build from Google’s repository and which I then use to compile the Chromium sources. Thanks to Void Linux for the pointers to fix this!
I will re-commence a build of proper Chromium packages in the hope that whatever I fixed for un-Googled Chromium will also be beneficial to the actual Chromium. And if not, then this will mark the moment that Chromium for Slackware is no longer able to sync your data with Google’s Cloud. In any case, an update of your Chromium (un-Googled or not) fixes a lot of nasty bugs and makes your Internet visits a bit safer.
I will keep you posted.
Eric
Thanks Eric. That it takes someone of your skills that level of effort is really quite concerning. It pushes the barrier really high for others to do so. Thank you for your efforts.
Eric, thanks for continuing to produce chromium and ungoogled-chromium packages for Slackware64 14.2, despite the amount of trouble you regularly run into.
I don’t use Google Cloud sync so this is not a problem for me (and so I can’t report and won’t complain about issues with it.)
This ungoogled-chromium update is working fine here.
TKS
Thanks Eric for the update of Chromium Ungoogled. It’s my main browser on my Slackware64 Current system.
I appreciate your dedication to builing the package despite all the difficulties.
Since I do have Slackware-current and Void linux dual boots, may be I could just move the Chromium Ungoogled binaries across?
Hi Nataraj,
I expect that the Slackware binaries for Un-Googled Chromium will also work on Void if its system libraries are not older than those of Slackware 14.2.
Keep the directory structures intact and use the wrapper script which is installed into /usr/bin to start the browser.
Hi alienbob,
Works in Void like a song! Thanx!
Thanks Eric! I use chromium-ungoogled as a backup for when Firefox doesn’t work for whatever reason on Slackware-14.2 (64-bit). (Apparently Firefox is too old and some websites refuse to work with it…)
excellent !
Thanks again Eric
— kjh
I’ll upload working Chromium 94.0.4606.81 packages for Slackware 14.2 and -current later today. Whatever I applied to fix the 32-bit build of the un-googled variant, also fixed the runtime crashes in Chromium.
Updating chromium (default, not ungoogled one) to v94, broke my browser sound in slackware64 14.2. Reverting to 93 give sound back.
Do you get an error or just no sound?
Same problem here:
Failed to create secure directory (/run/user/1973/pulse): Operation not permitted
The futex facility returned an unexpected error code.
(1973 it’s my UID)
See this Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1018580#c71
What happens if you start chromium with the additional command-line parameter “
--disable-features=AudioServiceOutOfProcess
” ?If that works, you can make it permanent by creating a new file like “/etc/chromium/02-audio.conf” with the content of:
CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --disable-features=AudioServiceOutOfProcess"
Using that parameter, no error shown and sound working (at least for me).
Thanks
Hi Eric, thanks for the workaround. Now sound works OK.
Wonder what change did they apply that broke sound.
I think this may have been caused by a change in configuration parameter when compiling Chromium. Normally I disable Google’s field tests in my browser build and “AudioServiceOutOfProcess” is one of these field test experiments for Linux which Google enables in their Chrome binaries.
For the 94 release this parameter seems to have changed from:
‘fieldtrial_testing_like_official_build=true’
to:
‘disable_fieldtrial_testing_config=true’
Next chromium package will use the new parameter and we’ll see if that fixes the issue which by the way has been reported on Windows and other Linux distros since at least 2019.
Thanks Eric.
I just want to report additionally that the comfig file workaround somehow does not work. However, passing the command line flag works every time. Thanks again!!
Eduardo,
It’s working for me. Make sure you are not overriding the CHROMIUM_FLAGS variable later on
jesusm@liet:~$ ls -l /etc/chromium/
total 16
-rw-r–r– 1 root root 150 Apr 12 2020 00-default.conf
-rw-r–r– 1 root root 416 Mar 4 2021 01-api-keys.conf
-rw-r–r– 1 root root 85 Oct 14 16:33 99-jmdp.conf
drwxr-xr-x 2 root root 4096 Oct 14 19:01 native-messaging-hosts/
jesusm@liet:~$
jesusm@liet:~$ cat /etc/chromium/99-jmdp.conf
CHROMIUM_FLAGS=”–password-store=basic –disable-features=AudioServiceOutOfProcess”
Using the 99 file I make sure my own parameters are the ones to use.
Jesús, I want to confirm that your suggestion about putting all in a “99-whatever.conf” worked well. Thanks!!
Just mind (Jesus and Eduardo) that you are discarding any previous value of the CHROMIUM_FLAGS variable. A value could have been set in another config file.
I am using my own proposed solution with a file “/etc/chromium/02-audio.conf” containing:
CHROMIUM_FLAGS="${CHROMIUM_FLAGS} --disable-features=AudioServiceOutOfProcess"
… thereby preserving and re-using any prior definition of CHROMIUM_FLAGS.
Yes, I was thinking on ‘adding’ my parameters to the already existing options, but I decided against that for practical reasons.
Ideally I should not just add (CHROMIUM_FLAGS=”${CHROMIUM_FLAGS} –disable …”) but instead replacing only the parameters I am interested on, using ‘sed’ maybe, while keeping the rest. But it was not worth of the effort in my case.
But of course, you are absolutely right, I am discarding completely any previous content of the CHROMIUM_FLAGS.
Yes, the config file workaround works for me. Thanks Eric, great job!
THanks for this and OBS!
I’m thinking Frescobaldi might be a lost cause, at least until the dev gives it some attention. Aside from the qpageview crash, when I rebuilt and installed python3-pyqtwebengine, it crashed a different way. It sounds like 3.2 is going to be a significant change (with qpageview becoming its own separate dependency). He seems to release things at Christmas and Easter, so that package might be in luck soon.
I noticed a poll on LQ created by volkerdi, asking whether Python 3.9 or 3.10 should be included in Slackware 15.0. My guess is that Python 3.10 is not yet ready to be adopted by the wider world.
Saw…not sure how big a pain in the ass reverting so many packages would be. Aside from Frescobaldi, my stuff is OK. I’ve been kind of pissed off at Frescobaldi for awhile, though. Granted, aside from that program and proton, I don’t use python all that much.
Recently “traveling light” bringing with me a small (10 year old?) HP pavilion notebook with Slackware 14.2 32bit and ungoogled Chromium installed I found no problems under way with e-mail / booking flight / bus / hotels.
To run Chromium 32bit (and to get rid of a “command line flag not supported” warning bar) creating the XFCE launcher by adding the suffix below was helpful:
–no-sandbox –test-type %U
To install uBlock Origin the advice found at:
https://stackoverflow.com/questions/35637278/offline-google-chrome-extensions
was helpful. Thank’s a lot for the hard work 🙂 – sincerely per
Thanks per. And good luck with your old 32bit computer.