My thoughts on Slackware, life and everything

Tag: chromium (Page 1 of 21)

Multiple Chromium updates in rapid succession

You may have noticed that after my release of the Slackware package for Chromium (and its Un-Googled sibling) version 146.0.7680.71 there was a really short interval until I released an update in the form of the 146.0.7680.75 version.

Chromium 146.0.7680.71 is the latest major version upgrade and it addressed a crazy amount of CVE’s. I am not even going to lookup and configure the URLs, here’s the list:

CVE-2026-3913 CVE-2026-3914 CVE-2026-3915 CVE-2026-3916 CVE-2026-3917 CVE-2026-3918 CVE-2026-3919 CVE-2026-3920 CVE-2026-3921 CVE-2026-3922 CVE-2026-3923 CVE-2026-3924 CVE-2026-3925 CVE-2026-3926 CVE-2026-3927 CVE-2026-3928 CVE-2026-3929 CVE-2026-3930 CVE-2026-3931 CVE-2026-3932 CVE-2026-3934 CVE-2026-3935 CVE-2026-3936 CVE-2026-3937 CVE-2026-3938 CVE-2026-3939 CVE-2026-3940 CVE-2026-3941 CVE-2026-3942

And then the next update to 146.0.7680.75 only two days later included 2 zero-day security fixes that the developers missed somehow: both for CVE-2026-3909 and CVE-2026-3910 an exploit exists in the wild.

And then already the next day, a new update emerged which I am currently compiling: Chromium 146.0.7680.80 sources were released to address yet another zero-day exploit, this time CVE-2026-3909.

Those new packages (chromium and chromium-ungoogled 64bit binaries) will become available tomorrow, Sunday if the compilation does not fail. The 32bit package for chromium-ungoogled will follow a day later. The last two attempts to build a 32bit package had to be aborted when I discovered that there was a new release. I have only one computer that is capable of compiling Chromium, and building packages in parallel is not an option.

Enjoy the weekend and be careful accessing shady web sites 🙂

Eric

Building Chromium for Slackware

I thought it would be helpful, and in any case insightful, to describe how I build the Chromium (also -ungoogled) packages for Slackware.

It is not a trivial task but a necessary one I believe. Slackware users should have a choice of browsers – some prefer Mozilla Firefox, others Google Chrome, and then there’s LibreWolf and Chromium that are built on the same code base as respectively Firefox and Chrome. There are others too, but I decided to stick with packages for Librewolf  and Chromium (-ungoogled). This article will focus on Chromium because Librewolf is pretty trivial to compile into a package.

Google develops the Chromium source code using tools which it partly created and maintains itself and for another part extends and patches them from the originals. Most notorious are the heavily customized Clang and Rust compilers used inside Google. The Chromium code reflects those compiler customizations because its codebase contains sections that will fail to compile using the official releases from the LLVM Project and the Rust Team (on which Slackware bases its own llvm and rust packages).

Google formally stopped supporting 32bit releases for their binary distribution of Chrome as long ago as 2015 (that’s ten years ago!) but indicated that the Chromium source code would still be compilable on 32bit platforms. Over time it became clear that internal code reviews and checks only happen on 64bit OS-es and the 32bit compatibility has been susceptible to “code-rot” ever since. As evidenced in my SlackBuild script where more and more patches and code modifications have been added to keep the ability to compile Chromium sourcecode into 32bit binaries.

Google provides binary snapshots of their internally used versions of Clang and Rust which reduces the need for patches a lot. Unfortunately Google at some point in time stopped providing 32bit binaries and so these binaries are nowadays only provided for 64bit machine architectures. In the past I relied on these binary snapshots to compile Chromium for Slackware.
After Google stopped providing those 32bit binaries, I have been putting a lot of effort in making Chromium compilable using the Slackware stock Clang and Rust compilers.

Note: I compile Chromium and Chromium-ungoogled on Slackware 15.0 and make these packages available in repositories for both Slackware 15.0 and -current. The challenge with Slackware 15 is that the provided llvm and rust compiler packages are way too old to be able to compile Chromium. Therefore Patrick Volkerding provides newer llvm and rust packages in the ‘extra’ section of the Slackware 15.0 repository. From time to time I run into new issues with clang and upon request, Patrick then builds and uploads a newer version of llvm into the repository.

Let’s have a look at the required updates for a Slackware 15.0 system (Slackware-current is up-to-date on all these package versions):

  • nodejs >= 20.13.0
  • llvm >= 21
  • rust >= 1.88.0
  • nasm >= 2.14
  • cmake >= 3.30.1

Some of these updates for Slackware 15.0 are in my own package repository (cmake, nodejs, nasm), some others in the ‘extra’ section of the official Slackware 15.0 package tree (llvm and rust).

When these updates are applied to Slackware 15, or in case you are running Slackware-current, compiling a Chromium package is simply:

# ./chromium.SlackBuild

… and compiling Chromium-ungoogled needs this commandline:

# USE_UNGOOGLED=1 ./chromium.SlackBuild

Note: you will need an enormous amount of RAM and lots of free disk space (in the filesystem which $TMP is pointing to) to run this build successfully, and then a lot of patience for that build to complete (my QEMU virtual machine needs about 12 hours to complete this build – per package).

From time to time, usually when the major version number of Chromium makes a jump, the source code has been modified to such an extent that the Slackware compilers will fail to build the binaries successfully. In that case (and if you are creating a 64bit package) you can force the SlackBuild to download and use Google’s binary clang and rust compiler snapshots using this commandline:

# BUILD_CLANG=1 ./chromium.SlackBuild

# BUILD_CLANG=1 USE_UNGOOGLED=1 ./chromium.SlackBuild

Usually this way the compilation will be successful.

Attribution:
Next to the Arch Linux PKGBUILD maintainer for Chromium, I depend more and more on the unparalleled knowledge of the NixOS package maintainers, to find the proper patches for my SlackBuild.
I would have been forced to drop the 32bit package support a long time ago if it were not for emilylange and networkException (NixOS) and Christian Heusel and Evangelos Foutras (Arch Linux).

I hope this article gave some insight into the life of a package maintainer.

Cheers, Eric

The bit-rot of 32bit Linux

Interest of software developers in the use of their product on 32bit Operating Systems has been declining for years. Build tests are only done on 64bit OS’es nowadays. For obvious reasons: there are not so many computers left in the Western world that only support 32bit software.
The thing is, there’s still a lot of old computer hardware in use outside of the wealthy West. Slackware is one of the few remaining Linux distros where the 32bit flavor is just as relevant as the 64bit variant. Yes, you may question the value of running really new software on really old hardware, but I think that is the users’ choice and if you happen to live in a country where a 2025 computer amounts to a year of salary, then I would want also those people to enjoy modern software and security patches.

I can’t recall how many patches have been needed to make source code compile on 32bit Slackware for instance, but in most cases there would be a way to patch the source or circumvent the error. Patrick Volkerding does this for the distro core and I do something similar for the packages in my own repository. And we sigh and complain to each other when compilations fail due to the restrictive 32bit address space, the inability to specify either “lib” or “lib64” as the LIBDIR, the use of architecture-specific assembly code and CPU instructions, etcetera.

But like with everything that’s left to rot in a corner, it’s getting increasingly difficult to keep 32bit Linux alive. I am running into huge time-sucks when packaging complex pieces of software. Specifically, I have not been able to compile 32bit Chromium since the 132 release despite all of my attempts. And now LibreOffice joins that list: I have been unable to compile the 25.2.0 release on 32bit Slackware 15 and -current.

So.
I will give up my attempts to create 32bit packages for future Chromium and LibreOffice releases. It has already taken way too much of the little time I have left after my regular day-time job. If I run into more of these programs that won’t allow me to compile 32bit binaries, those will quickly be added to that list as well.
I will ask again: if there are people among you (readers) who really need their 32bit programs, I need you to come up with the patches to make that work.

As long as there is a 32bit Slackware, I will keep maintaining my multilib repository of course: there’s nothing for me to actually compile there now that gcc and glibc packages in 64bit Slackware support multilib; the work is reduced to simple re-packaging. But once Patrick decides that 32bit Slackware goes the way of the dodo, then also multilib for Slackware will disappear. It would really be a shame though, but there’s simply no longer any kind of movement that is sufficiently influential to be able to sway software developers and keep 32bit Linux instances running to do their unit testing.

Looking at the Wine emulator, that one can be built so that it no longer needs 32bit libraries, but it would lose the capability to run 16bit Windows programs. I guess that’s where DOSbox would come in to save the day.

But be forewarned: the 32bit OS has become an endangered species.

Eric

Quick ungoogled chromium tips

Hey folks. While working I needed to find a historical page in my Chromium browser history and failed. I thought “here we go again” and decided to share some quick tips for users of Ungoogled Chromium at the year’s end.

  • I run into this issue from time to time on computers where I use Chromium. The Chromium browser will keep your browsing history only for 90 days and deletes everything that’s older. This is a hard-coded limit in the source code.
    However, for Chromium’s Ungoogled sibling there’s actually a flag which allows you to disable that 90-day limit and you can keep your browsing history forever.
    Open “chrome://flags/#keep-old-history” in chromium-ungoogled and toggle its value to “On”.
  • The first time you run Ungoogled Chromium, it shows you a startup page full of helpful information to ease the switch from Chrome, such as how to install the Chrome Web Store. But  that page does not return later and it’s not available in the menu.
    You can however always go back to that page by opening “chrome://ungoogled-first-run/” in chromium-ungoogled.

Nothing fancy, just thought to share this.

Be safe during the New Year’s Eve fireworks.
Eric

Chromium source tarball availability

Someone asked how I am creating Chromium (also -ungoogled) packages these days? When you download my SlackBuild script and attempt to build the package yourself, the script will error out because it cannot download the sources.

For weeks now, the Google automation is broken with regards to creating Chromium source tarballs. Apparently some bug prevents their CI/CD pipelines from succeeding. This is reportedly fixed for the Chromium 132.x releases (currently their Beta versions) but Chromium 130 and now also 131 releases are announced without their accompanying source tarballs.
I have therefore created a script which fetches the needed stuff from git and packs that into a “chromium-$VERSION.tar.xz” tarball. You will find it in the “build” directory and it’s called “fetch-chromium-release.sh“. You run that script with a Chromium official version number, wait a long long time, and you end up with the 6+ GB source tarball which you can then move into your local “build” directory.

Hope that clarifies things and helps you compile chromium or chromium-ungoogled yourself.
Have fun! Eric

« Older posts

© 2026 Alien Pastures

Theme by Anders NorenUp ↑