My thoughts on Slackware, life and everything

Category: Software (Page 1 of 145)

In the works: LibreOffice 24.2.0 for Slackware 15.0

Apart from post-COVID syndrome there were some other setbacks lately, but those were mostly software-centered. Like the fact that I can not build a 32bit Chromium package for instance.
But also the realization that the latest LibreOffice 24.2.0 can no longer be compiled on Slackware 15.0 – its gcc 11.2.0 compiler is considered “too old”.
With the help and insight of Pat Volkerding I was able to compile LibreOffice on Slackware 15.0 anyhow:

I need to test the resulting binaries, and I still need to see whether I can repeat this on 32bit Slackware of course… but it looks promising.
More to follow.

Update 2024-Feb-21:

+--------------------------+
Wed Feb 21 12:41:50 UTC 2024
libreoffice: updated to 24.2.0 for Slackware 15.0 and -current.
Depends on openjdk17.
openjdk17: added v17.0.10_7 for Slackware 15.0 and newer.
Only install one version of Java!

Cheers, Eric

Chromium 121 for Slackware… don’t hold your breath

Chromium 121 sources were released yesterday, and as much as I would like to tell you that the Slackware packages are ready, in fact it appears that you will have to wait for them for an unspecified amount of time.

I found out that the build of Chromium now needs Google’s custom version of the Rust compiler, next to Google’s custom version of the Clang compiler. Those Rust and Clang versions are intertwined and Google advises packagers to simply use their own pre-compiled binaries which they provide for download.

You guessed… those binaries are not available for a 32bit OS. Nothing new, and it is for that exact reason that as part of compiling Chromium for Slackware, the complete LLVM toolchain is built from Google’s sources first. For every package I release. Tweaking the LLVM/Clang compilation so that they work for 32bit Slackware took a lot of time – after all, no one at Google tests their sources for 32bit build compatibility. So I patch here and there and every time feel lucky that it still works.

Until today, when I ran into the new Rust requirement. And after the umptiest iteration of a Chromium package build using a variety of changing options, I still fail to even start compiling a Rust binary.

I am taking a break from this to consider my options. My aim is to keep supporting the 32bit Slackware package. I just need to figure out how Google messed this up again and find a way around it. In the meantime, don’t hold your breath – I only have a few hours each evening to do the troubleshooting. A new package will appear when it’s ready.

All the best, Eric

Update 2024-jan-29: I have buillt 64bit packages for Chromium (also -ungoogled) version 121.0.6167.85 and uploaded them to my repository.
Note that I can not currently compile their 32bit versions because until now I have not been successful in building Google’s custom llvm and rust from source. I had to revert to downloading and using Google’s pre-compiled binaries which they only supply for 64bit systems.

I am still determined to find a way to compile these llvm and rust compilers from Google’s own sources. But I have no ETA on that unfortunately.

I switched the Wiki theme as well

Last week I told you about the change of theme which I applied to my personal blog. It seems that I was not done then.
On a different server I host the SlackDocs Wiki (https://docs.slackware.com/) and a lot more than that Wiki actually; docs.slackware.com is the same host which also provides you with the slackware.nl mirrors. This host is a physical server running in a datacenter on Slackware64 15.0 – nice and stable.

For an unrelated service I decided to upgrade the stock PHP 7.x to the 8.x version you can find in the ./extra directory because that is a version which offered better support and speed for that particular service.
Only the next day I found out that the PHP upgrade broke the Dokuwiki software which is what SlackDocs Wiki is actually based on. I could not use the Wiki’s admin interface to repair what got broken (afterwards I assumed I may have been thwarted by old cached PHP code; Dokuwiki obtains its rendering speed by caching the compiled PHP code so that it does not have to retrieve the script code all the time). Anyway, on the commandline I was able to upgrade the Dokuwiki to its latest version and along with that, all the plugins that I installed to extend the Wiki syntax or providing community editing capabilities.

So far so good, but the Wiki was still not rendering correctly with persistent errors in the browser and in the Apache httpd logs. They turned out to be caused by the Wiki theme (in Dokuwiki it is actually called a ‘template‘ not a ‘theme‘ like the blog). For SlackDocs I have been using the “MonoBook” template since its inception. The MonoBook template for Dokuwiki is inspired by the look and feel of the original MonoBookskin‘ for MediaWiki (the wiki engine powering Wikipedia) which was replaced by the Vector skin in 2010.
This MonoBook template has not been updated since 2014 and is no longer supported by the latest Dokuwiki. Eventually I was able to fix the ‘bad code’ in the template and now the Wiki renders just fine using it.
But it got me thinking that it might be wise to switch to a supported theme. That sounds trivial, but I chose MonoBook for a reason: it supports Discussion pages. When you open a SlackDocs page, you will find a couple of tabs above the article, called “Article“, Discussion“, “Read“, “Edit“, “Old revisions” and “PDF export“. The Discussion tab allows anyone to comment on the actual article and thus hopefully spark a discussion – with the author or with other readers.
So I needed another template with that same Discussion capability. That was not so hard in the end; the same person responsible for the MonoBook template is also maintaining a Dokuwiki port of Mediawiki’s Vector skin. And even though it has not been updated either since 2014, Vector is fully supported by the latest Dokuwiki – no errors in its code.

I have ported the SlackDocs configuration for MonoBook to Vector and enabled it. The result can be seen on the current instance of SlackDocs Wiki. Most notable  change is that the search entry field is now located at the top right of the page instead of halfway the left sidebar. Well, and it looks subtly different than MonoBook of course.

I hope you like it… but it’s not that I would go back to MonoBook if you don’t.

Enjoy! Eric

 

KTOWN Live ISO based on liveslak-1.8.1 and Plasma6 Beta2

My work on the new Plasma6 for Slackware finally reached a level that I am OK with. I have uploaded a new KTOWN Live ISO image based on liveslak-1.8.1 and it contains a fully functional KDE Plasma6 Beta2 release.

The ISO is 5.2 GB in size, it is huge. Slackware has come to a point (already a while ago) where the full release does not fit on a DVD medium anymore. It’s the new age of digital, it’s really easy to install the distro via a network mirror, and if you want to run it off physical media (like the Live environment) a USB stick is required. I can really recommend using a Ventoy USB thumb drive onto which you can simply copy the full un-modified ISO image and then boot from the stick.
Making the Live environment persistent when you boot from an ISO file is detailed in an update to the liveslak documentation.

Points of note:

  • Plasma6 Beta2 is based on Qt 6.6.1 and consists of: KDE Frameworks5 5.113.0, Frameworks 5.247.0, Plasma 5.91.0 and Applications 24.01.85; The Frameworks5 package-set is still needed to support KDE Plasma5 applications.
  • Pipewire is the default audio server, fully replacing Pulseaudio.
  • The default graphical session is still X11 based but Wayland is fully functional and stable and you can select it from the SDDM session dropdown list.
    When you boot to runlevel 3, the command “startkwayland” will also give you a full Wayland session.
  • I added xwaylandvideobridge to allow Wayland windows to be streamed to X11 applications. You’ll need this to share your screen in applications like Discord, Skype etc.
  • I will soon make available in the ktown repository, my sources and scripts as well as the ‘deps’ packages (such as the new qt6 package and several Slackware originals recompiled to add Qt6 support to them).
  • I also added a background to celebrate the festive season, taken here in Brabant during a COVID pandemic winter walk. The two ice-skaters in the background, that’s not us 🙂

Get the new ISO from one of the following locations (the ISO is accompanied by a MD5 checksum file and a GPG signature):

Tell me what you think of it and what issues you ran into that I might be able to fix in either the Slackware packages or else in liveslak. Don’t forget to report actual functional issues to the KDE bug tracker: https://bugs.kde.org/

Have fun! Eric

Google fixes the 8th zero-day in Chromium in 2023

Chromium 120.0.6099.129 for which the source code was released two days ago repairs a zero-day vulnerability.

Zero-day means that the vulnerability is already actively exploited in the wild. Hopefully the last time this year, but it is already the 8th zero-day which was reported and fixed in Chromium. The new zero-day is labeled CVE-2023-7024.
It’s therefore highly recommended to upgrade your chromium and also ungoogled-chromium packages.

Find the updated Slackware 15.0 and -current packages both for chromium and chromium-ungoogled in my repository and its mirrors (like my own US server and in a short while, the UK mirror).

Cheers, Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑