Monthly Archives: October 2021

liveslak-1.4.0 and new ISO images are available

It’s that time again for a fresh batch of ISOs for Slackware Live Edition.
The ISO files are based on Slackware-current of “Sat Oct 23 18:57:30 UTC 2021” and using the liveslak-1.4.0 scripts.

The Slackware-current snapshot on which the Live ISOs are based contains a Linux 5.14.14 kernel.
This is not yet the pre-emptive variant of 5.14.14 which you can find in “./testing” inside today’s Slackware-current mirrors. However, you can use liveslak’s “upslak.sh” script to easily upgrade the kernel on your persistent USB Live if you want.
It’ll be interesting to see how it improves real-time performance on the DAW Live platform.

The new ISOs for the Slackware Live Edition can be obtained at download.liveslak.org .

Note that a new “DAW” ISO variant is missing for the moment.

Update 28-Oct:
I have uploaded a DAW ISO to the ‘latest‘ folder. It is based on liveslak-1.4.0.1 using kernel 5.14.15 and with full preemption enabled out of the box.

The upgrade in Slackware of Python to version 3.10 forces me to do a lot of re-compilations or upgrades of the software that has a Python3 dependency and unfortunately in the DAW package set, that’s quite many of them.
Give me a couple of days and the new DAW ISO will appear on the above URL. I’ll try and make a liveslak-1.4.0.1 release that supports the preemptive kernel in ‘testing’ and enables the full preemption model on boot of the DAW Live.
In the meantime, you can still obtain a DAW ISO from a month or so ago in the “1.3.10” directory.

I refreshed he ‘bonus‘ section as well with updated live modules for the binary Nvidia driver (already contained in the CINNAMON, DAW and MATE ISOs by the way), the Broadcom STA driver (wl) and an uptodate multilib package collection.

Hghlight for liveslak-1.4.0 is the extended syntax for the ‘persistence’ boot parameter. You can now point your Live OS to a persistence directory or container which is located in a subdirectory below the filesystem root.
Additionally, you can specify the partition containing the filesystem on which the persistence is located, or simply specify ‘scandev’, to request that liveslak tries to find the partition for you:

persistence=/dev/sdX:/path/to/mypersistence
persistence=scandev:/path/to/mypersistence

In addition, a UUID or LABEL value of the filesystem is accepted:

persistence=cd68b6f5-5b5a-4d27-9649-7827489f94a5:/path/to/mypersistence

This creates opportunities for PXE boot where persistence was not possible; the live modules will get mounted from a NFS export and the overlay filesystem does not support writing to a NFS layer. Storing your persistent data on a local hard drive or even a USB stick that you plug into the PXE client computer will solve that predicament.

Have fun! Eric

Package updates as a result from the switch to Python 3.10 in Slackware-current

When Python3 was updated from 3.9 to 3.10 in Slackware-current two weeks ago, lots of 3rd-party packages (i.e. software packages that are not part of the Slackware distro itself) containing python modules were suddenly broken.
To make things more complex, not all Python software is currently compatible with Python 3.10. Patrick Volkerding opened a poll on LinuxQuestions.org to get feedback from the community about this intrusive update after we already have a Slackware 15.0 Release Candidate since mid-august.
After all, when you tag a Release Candidate, that usually sends a signal that the software set is frozen and only usability issues and software bugs will be addressed.

After giving this some time to sink in and hoping that this update would be reverted because of its impact, I now think we are stuck with Python 3.10 in Slackware. Which means I had to start looking at which of my own packages are now broken.

This will require time I am sure. time which I do not have in large quantities, so I am going to do this incrementally and with a sense of prioritizing. Top-most I am going to work on the packages that are actually reported to me as being broken.

Today’s message for you is that I have fixed the Inkscape package in my repository. Inkscape is a complex program for creating vector graphics (SVG images for instance). Complex in the sense that it has many dependencies and some of these were also broken – due to recent boost, icu4c and python3 upgrades in Slackware. The sum of updated packages is therefore: inkscape, libcdr, python-lxml, python-numpy and scour.

Let me know if there’s other software in my package repository for -current that’s currently broken. I do not use all that software myself so in some cases I will be totally unaware of any ‘broken-ness’ until you tell me.

Cheers! Eric

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 : documentliberation.org . 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!
Eric

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 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