Category Archives: Software

LibreOffice 7.2.2 for Slackware-current is available

LibreOffice Community Edition 7.2.2 was released yesterday and I have uploaded a new set packages for Slackware-current.

The document conversion libraries have been split off and made available via the Document Liberation Project : . It is the home for a growing community of developers ‘united to free users from vendor lock-in of content‘. Software like Calligra, Inkscape and Scribus also make good use of the document format conversion capabilities these libraries offer.

Enjoy the new packages!

Un-Googled Chromium update for Slackware 14.2 and -current

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

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.


Gentoo eudev adopted by Eudev Project

A recent LinuxQuestions thread discusses the depreciation of the eudev fork which was created by Gentoo a few years back in order to keep systemd at bay. This step by Gentoo sparks some serious doubts among LQ members about what Slackware should do – is the inclusion of systemd near, now that eudev is dead?

Short recap: In November 2015 Slackware replaced its no longer maintained original udev with this new eudev (a standalone extract of udev out of the systemd sources but modified so that every dependency on systemd is removed). This change was actually my chance to announce the liveslak project as a ‘celebration to say farewell to udev‘.
In November of 2020, a similar event happened when Slackware replaced ConsoleKit2 with elogind – a standalone copy of the logind code extracted from systemd and with all dependencies to systemd removed. Both events were meant to keep Slackware free of systemd, at least for a while… who can stem the flow of water.

But there is good news. Yesterday, a collaboration between Alpine, Devuan and Gentoo contributors has announced their adoption of eudev and a new repository has been created where the new project will further develop eudev: . Let’s give these folk our best wishes!


Update your Chromium to 93.0.4577.82

Today, I uploaded a set of Chromium 93.0.4577.82 packages for Slackware 14.2 and -current (32-bit as well as 64-bit).

According to yesterday’s official announcement on the Google blog, this release patches a number of vulnerabilites and two of them are zero-day vulnerabilities that are actively being exploited online.

The advice is to upgrade Chromium on your Slackware 14.2 and -current computers as soon as possible.

The ungoogled-chromium sources are lagging behind as usual, but I have hopes that a new source tarball will appear soon, now that we have a Chromium update which addresses multiple zero-days. Eloston, the project maintainer, seems AWOL but several contributors have a working patch set ready.

Stay safe! Eric

liveslak-1.3.10 and new ISO images for Slackware Live Edition

The previous batch of ISOs for Slackware Live Edition is already a few months old, so I decided to generate new images.
The ISO files are based on Slackware-current of “Wed Sep 8 18:07:38 UTC 2021” and using the liveslak-1.3.10 scripts, where passwordless login is a new feature.

Slackware-current has the label “15.0 Release Candidate 1” since August 16th but considering the amount of non-trivial updates since that date, I wonder whether the phrase “release candidate” has any relevance here. No sign that we are anywhere nearer to a final 15.0 release.

Let’s hope for the best, and in the meantime fresh ISOs for the Slackware Live Edition can be obtained at .

I refreshed he ‘bonus‘ section as well. There you find several squashfs modules you can use with your persistent liveslak USB stick. Copy these module into the ‘addons’ directory on the USB drive. They expand the functionality of the Live OS and allow me to keep the ISO file size within reasonable bounds.
Among these you’ll find the binary nvidia driver (already contained in the CINNAMON, DAW and MATE ISOs by the way); Wine 6.12, multilib, the DAW package collection, and a set from my own repository (chromium, libreoffice, veracrypt, vlc etc).

To end this post, I have a question for you regarding liveslak functionality.
At boot you can add any number of parameters to the kernel commandline, and some of these are used by the liveslak initialization. A subset of these parameters cause modifications of files in the live filesystem. For instance, “livepw=” will update /etc/shadow and /etc/passwd to update the password for the ‘live’ user. You can specify a domain name, custom hostname and a lot more which will cause modifications of files in the live filesystem.
Now the crux of the issue: if you have a persistent Live USB stick, do you want these parameters to make permanent changes to your Live filesystem? Or do you want them to be ignored if you are booting a persistent USB stick?
I can see good reasons for a limitation of the scope of these parameters, to just the non-persistent Slackware Live (i.e. when booting from a DVD). I also realize that it would be a functional change that can impact the way some of you work with a liveslak medium.

Let me know (in the comments section below) if you would like liveslak to ignore certain boot parameters if you boot a persistent medium.

Have fun! Eric