Alien Pastures

My thoughts on Slackware, life and everything

Category: Software (Page 1 of 151)

Building Chromium for Slackware (contd.)

December 6, 2025 / / 0 Comments

It’s been ‘fun’ compiling the newest Cheomium 143 sources… as usual when Google updates the major version number.
Again, it is momentarily not possible to compile the Chromium sources using Slackware’s own compilers. I get a Rust error “error: extern blocks must be unsafe” in compiling ‘liballoc_error_handler_impl_ffi.rlib‘. which I have been unable to fix – my knowledge of the Rust programming language is non-existent.
Which is why I could only upload the 64bit packages for chromium and chromium-ungoogled; Google only offers a 64bit version of the heavily patched clang and rust compilers they use internally to compile Chrome. A 32bit package will only become available after I found a fix for the Rust error.
Also, I had to apply some hacks in order to deal with the need for a newer Python than the 3.9 which is part of Slackware 15.0. I already have a successful patch for another part of the code where Python 3.9 was too old (the pipe union operator ‘|’ was added in Python 3.10) but due to time constraints I could not examine the new code and instead added a Python 3.12 binary in parallel.

This means you currently cannot simply run the SlackBuild on Slackware 15.0; you have to add a Python 3.12 package (I compiled a package from the sources I took from from Slackware-current) and point the ‘/usr/bin/python‘ symlink to python3.12. I hope to have fixed that requirement in the next batch of chromium packages.

Building Chromium for Slackware

November 8, 2025 / / 8 Comments

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

Anubis is now guarding the git server

August 24, 2025 / / 11 Comments

I have had it with the onslaught of AI and indexing bots that keep my web servers in a constant state of near-crashes.
In particular git.slackware.nl is not handling the load well. It’s powered by cgit, and with tens of thousands of requests per hour to serve the details of git commits, cgit experiences a lot of segfaults. I already had to disable the download of compressed git-snapshot tarballs because all the “xz” processes that were running as a result of serving up “tar.xz” files were eating most of the server’s resources.

The filters that I had built into the Apache httpd server, as well as fail2ban taking care of the really obvious offenders, were not sufficient.

So. I have built a package for anubis, the self-proclaimed Web Application Firewall that protects web sites from AI scraping bots by challenging the visitor with a proof-of-work. This is essentially a calculation the client (a browser, or a web-scraping script) has to make before allowed entry. That calculation takes the shape of a small math problem that is expensive to compute, but easy to verify, like hashing a string with a given number of leading zeroes.
For scraping bots, the cost of these calculations will be big enough that they stop trying. Mere individuals like you and me, we will notice the Anubis loading page for a second and then it will stay out of our way as long as the cookie it places is valid.
Common Linux download programs like wget and curl are not affected by Anubis because it uses  a sensible set of defaults in its filtering behavior with the intention to not infuriate the humans accessing the site.

The anubis package that I built, will create an ‘anubis’ user and group when it is installed. It will also install a startup script in ‘/etc/rc.d/’ and a block is added to ‘/etc/rc.d/rc.local’ so that Anubis will start on every boot of the computer.

Anubis can run in multiple separate instances. A necessity because for each web site you want to protect you’ll have to run a separate instance, listening on a separate TCP port.

If there’s interest in the details of setting up Anubis on Slackware, let me know in the comments section below and then I’ll write up that documentation in a follow-up article.

If you experience issues accessing git.slackware.nl because of Anubis, also let me know below!

Cheers, Eric

A Slackware theme for your Grub

August 16, 2025 / / 12 Comments

Long ago, when all we had was 32bit Slackware and I was working on realizing the 64bit variant of Slackware, I created a ’64bit’ lilo bitmap with the Slackware  logo, to make it more obvious to your friends that your computer is booting 64bit Slackware and not some obscure other distro.

Lilo is getting a bit old in the tooth though. Mdern computers come with UEFI instead of good old BIOS, and that computer cannot boot on lilo. You’ll have to use elilo or grub instead.
Until now, Slackware supported elilo in the distro installer, but if you wanted to give your computer a Grub bootloader instead of elilo, you would have to do that manually right after the installation of Slackware is completed. Or you could swap out elilo for grub at any later time of course – it is not difficult.

Slackware-current is working its way toward making Grub the default bootloader. The process of installing or upgrading kernels is now automated to the level that if you have Grub installed as the bootloader, there’s nothing you need to do yourself: an initrd is generated based on your preferences (preferences can be written to the files /etc/default/grub , /etc/default/geninitrd and /etc/mkinitrd.conf), the grub bootmenu is refreshed and that’s it!

Recently I switched to Grub on this laptop which until then had been happily booting via elilo. As you may have seen, I use a nice graphical boot screen in liveslak and when I booted this laptop via Grub the first time, I was a bit disappointed by the text-only boot menu much like the boot experience I had with elilo.

But I like my liveslak boot screen!

So I set myself to finding out how I  could install and enable that same boot screen in regular Slackware.

The result is in the ZIP archive http://www.slackware.com/~alien/liveslak-grub2-theme.zip . Here’s how to use it to get a nice boot splash on your Slackware computer with Grub (the prior installation of Grub is something I leave to you):

  •  Extract the archive containing the Grub theme into directory /boot/grub/themes/
  • You will now have a new directory /boot/grub/themes/liveslak-grub2-theme – change its name to /boot/grub/themes/liveslak
  • In the file ‘/etc/default/grub‘ add or modify the following lines:
    GRUB_THEME=/boot/grub/themes/liveslak/theme.txt
    GRUB_FONT=/boot/grub/themes/liveslak/dejavusansmono12.pf2
    GRUB_GFXMODE=1024x768,800x600,640x480,auto
    GRUB_GFXPAYLOAD_LINUX=keep
  • Then run (as root) the command: update-grub
  • Now, reboot. You should be greeted by a Slackware logo and the Grub boot menu.

Let me know in the comments section what you think of this!

Cheers and enjoy the weekend, Eric

RFC: How to build my Wine package

June 29, 2025 / / 7 Comments

I have a question for you – hence the “Request For Comment” in this post’s title.

I have been compiling a Slackware package for the Wine emulator for a long time now. The 64bit wine package contains both the 64bit and the 32bit Wine binaries and libraries.  It therefore also requires that you made your 64bit Slackware into a multilib system.

For a while now, Wine can be built in another way than I have been doing it traditionally. The “WoW64” build aka “Windows on Windows64” allows you to run 32bit Windows binaries on a pure 64bit Slackware Linux OS, no multilib required.
Caveats of a switch to a WoW64 build of Wine for Slackware:

  • The WoW64 build does not support 16bit Windows binaries.
  • You may have to re-create your 32bit Wine prefixes.
    Meaning, the Windows programs which you already have installed on your computer have been written to what’s called a “Wine prefix”, basically a subdirectory in your homedirectory (the default location is ~/.wine/).
    Usually you would not bother with the concept of the Wine prefix, but it allows you to isolate various Windows programs from each other. Suppose you need to install additional Windows libraries via tools like winetricks (the same script is called ‘protontricks‘ if you use Valve’s Proton instead of Wine). but the DLL requirements are conflicting between Windows programs. Then you install each program into its own Wine prefix.
    Bottomline: it may cost you some one-time work to get your programs going again.
  • There’s some reports about performance regressions in Wine 9.x under WoW64 for 32bit Windows programs that invoke OpenGL calls directly. I can not confirm that this has been addressed in Wine 10.x
  • Valve’s Steam gaming platform still requires multilib on your computer.

Therefore I would like to hear your opinion about whether or not to switch from traditional multilib Wine to the new WoW64 Wine.
With “you” I mean actual users of my Wine packages. I am not interested in random replies.

Let me know below!
Eric

« Older posts

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑