After I built a fresh Avidemux (see previous post) I realized how many old packages I still have in my repositories. They are taking up space on many server mirrors.
I have decided that I will start a cleansing process, a purge if you want, of all the older stuff. The reason is not just disk space of course. It’s my realization that there may be vulnerabilities in these old packages that I never addressed; and I really hope that people have migrated their machines to Slackware 14.2 (servers or conservative desktop users) or went with -current (modern desktop users, let’s call those).
From time to time, you need to clean house. I myself am infamous for not throwing away anything… just take a look at my attic. So these packages will be gone from online servers, but live on in my own local package archive.
Because of the time involved (manual checks to ensure that I don’t remove too much by mistake) this will be done in several ‘waves’. My repositories already don’t have packages for Slackware releases older than 13.37 and tomorrow I will purge all packages targeting Slackware 13.37. Later, that will be followed by a purge of all packages for Slackware 14.0, and finally those that were meant for Slackware 14.1 will also be removed. I will stick with package support for Slackware 14.2 (and 15.0 when that gets released) and always -current.
In case you still run one of these older versions of Slackware, you would want to make local copies of the following repositories ASAP:
I have an avidemux package in my (restricted) repository.
But… it had not been refreshed since Slackware 14.0 (8 years old now) and its binaries stopped working on Slackware long ago. Looking back at the packaging work I did today, I guess the thing that kept me from updating that Avidemux package was the numerous dependencies that also needed an update (they all were stuck at an old Slackware 14.0 release).
Based on the imminent (fingers crossed) release of Slackware 15.0 according to Patrick himself, I decided to create these packages only for Slackware-current (soon to become 15.0). I also cleaned out ancient versions of all these packages. They are now removed for Slackware 14.1 and older.
Note that faac and libfdk-aac just like avidemux contain patent-encumbered software (the AAC encoder) and due to that circumstance the three packages are banished to my ‘restricted repository‘ which is hosted outside the US of A so that the patent trolls won’t bother Pat.
Let me cue you in about Avidemux in case you are not familiar with the program.
It’s a video editor supporting many video formats thanks to the built-in ffmpeg libraries and many plugins. It allows for a decent level of automation through tasks and scripts, and it has a command-line interface next to its Qt5-based graphical user interface.
Some of the 2.8.0 release highlights: Avidemux is now able to convert HDR video to SDR with tone mapping using a variety of methods. The FFV1 encoder has been added again. TrueHD audio tracks can be decoded and are supported for Matroska containers. The internal ffmpeg libraries are the latest 4.4.1 version. It integrates better with pulseaudio in terms of volume adjustments.
It was already a while ago that I refreshed my ‘steamclient‘ package for Slackware.
The steamclient package is meant to bootstrap the installation of Valve’s Steam gaming platform on your Slackware computer. The package installs a couple of scripts and a 32-bit Linux runtime based on Ubuntu. When you first start ‘steam’ from the menu or from the X terminal commandline, the client will download a larger set of runtime libraries, including 64-bit support. Onwards, the client will keep its runtime libraries up-to-date automatically, every time it starts up and connects to the Steam servers.
The Slackware package has a couple of tweaks because we obviously do not have Ubuntu tools on board. As a result, on Slackware-current (32bit and 64-bit with multilib) Steam works out of the box.
The reason for a package refresh is a recent bug report on Valve’s github, about an ALSA related crash on Slackware. The root cause was eventually found and it was part of the customization I added to the steam launcher 6 years ago when we were still on release 14.1 and we did not have pulseaudio as part of the Operating System.
So I removed (actually, commented-out) these lines, and that should fix the root cause for that bug. If you do not use Pulseaudio or want to enforce ALSA sound regardless, just un-comment the relevant lines at the top of the ‘/usr/bin/steam’ script again – it’s self-explanatory.
I have also refreshed the READMEs for Slackware and additionally removed support for all Slackware versions older than 14.2. To be realistic, I assume that gamers are all on the -current platform already.
If you have an older ‘steamclient’ package installed on 64bit Slackware and use the slackpkg+ extension to manage 3rd-party repositories, you need to un-install the old steamclient package first. The old packages have a ‘i386’ architecture tag whereas the new one has a ‘i386’ architecture tag for the 32bit Slackware, and a x86_64 tag for use on 64bit Slackware.
They are the same package actually but I was asked to make ‘steamclient’ installable via slackpkg/slackpkg+ also on 64bit Slackware. So:
Some other recent package updates in my Slackware-current repository are:
Wine: we’re up to version 6.23 now. The 32bit wine package is just that – 32bit Wine. My 64bit wine package contains both 64bit Wine and the 32bit WoW64 (Wine on Wine64). Both have the ‘staging‘ patches applied.
The external dependencies for this package remain the same: FAudio and vkd3d are required. On 64bit Slackware you need to have multilib installed. In addition to multilib, you need to convert the 32bit versions of the FAudio and vkd3d packages to ‘compat32’ packages and install those.
MinGW-w64: I have updated this package to v9.0.0_gcc11.2.0. Mingw-w64 is based on the original mingw.org project (which was created to support the GCC compiler on Windows systems), particularly adding 64-bit support.
The MinGW compiler suite is used to generate the native Windows DLLs in the wine package.
The QEMU machine emulator and virtualizer got a refresh because I am preparing (fingers crossed!) for a release of Slackware 15.0 which according to an online statement could happen soon after New Year 2022.
I run Slackware Virtual Machines (VMs) in QEMU and I wanted to take advantage of the newest QEMU features. At the moment my VM host is Slackware 14.2 and that has a fairly old QEMU package installed. The VM host will get an upgrade to Slackware 15.0 as soon as the new release is made available.
Dependencies for my qemu package are: vde (historically for non-root network bridge support) and as of now also: device-tree-compiler, jack2 (note that jack2 has its own sub-dependencies!) and virglrenderer.
Have fun with these during the holiday break, and I wish you all a Happy New Year.
New ISO’s for Slackware Live Edition (based on liveslak-1.5.1) are available for download. You’ll find SLACKWARE (32bit/64bit), XFCE (32bit/64bit), DAW, LEAN, CINNAMON and MATE updated images (see below for download locations). I also refreshed the ‘bonus’ section with nvidia and broadcom-sta drivers matching the installed kernel, and other useful stuff.
All 32bit ISOs will boot a SMP kernel from now on, since the non-SMP kernels still refuse to execute the init script in the initramfs.
Firewall testers needed
This newest release of liveslak brings something that was recently discussed on linuxquestions.org. What about adding a basic firewall configuration to the freshly installed Slackware system? A new Slackware Linux computer may have several ports open already and some people are paranoid about any prying from the outside.
You will find as many firewall ideas as there are people in the discussion. So I based the core of the liveslak firewall on the code of Easy Firewall Generator of which I host a slightly modified version at http://www.slackware.com/~alien/efg/ . I added ipv6 support too. I know that this is old code, it’s also still using iptables instead of nftables but I wanted something functional that I knew well.
But in particular I want people to test the dialog-based configurator and give me feedback. You’ll notice that the configurator allows you to go back and forth in the various dialog windows. I also want to know what you think of the questions and the level of simplicity. Also look at the installed rc.firewall script. Does it do what you need it to do?
Also, does the resulting firewall configuration what you expected it to do? Is there anything that does not work?
Now, how does this firewall configurator work and where do I find it anyhow?
Every liveslak ISO since liveslak 1.5.1 has this functionality included. The firewall configurator will be invoked only when you use the (also included) setup2hd script to install the content of the Live ISO to your hard drive:
Adding a firewall is an optional step! You can choose to skip it during installation. The relevant files will be installed to your computer and you can call “myfwconf” at any time in future if you change your mind.
Note that this is a simple firewall. It does not do any NAT, it is meant for a single-homed single-purpose personal computer running Slackware which you want to protect from external attacks. The rc script will add a lot of sysctl tweaks to make your system safer, this is independent of opening (or not) any TCP or UDP ports via iptables.
Do I get this firewall when I use a Live ISO to install regular Slackware?
The firewall configurator is not available during installation of regular Slackware (i.e. from a HTTP/FTP mirror or a NFS/SMB network location).
If you would like to see the option of installing a firewall also for a regular Slackware installation, let me know. I am open to suggestions.
During the installation of the Live OS to your hard drive, the firewall dialog is inserted to the pkgtools setup directory so that it will be called during Slackware’s post-install configuration. The first question you will see when going through the configuration steps of your fresh installation is whether you want a firewall at all. You can opt out at this point, by selecting “No”, and no further questions will be asked:
Next you will be asked to select the external network interface(s) that you want to have firewalled. Sometimes you’ll have more than one network interface (such as a laptop with its wired and wireless interfaces) which you want to protect with a firewall. This dialog will show you all detected interfaces and will have the one with the default gateway selected by default:
Next question to answer is whether you want a firewall to completely block all external connections (excluding DHCP traffic) or that you want to have specific ports open to the outside. Select “No” if you don’t want a completely blocking firewall:
If you selected “No” in the previous dialog, you will be presented with a choice of common network protocols that you can open up from the outside by selecting them:
The next dialog allows you to specify additional TCP/UDP ports and/or port ranges to remain open:
You will have a final opportunity to review the choices you made:
Pressing “Generate” will generate ‘ipv4’ and ‘ipv6’ configurations for iptables in the directory ‘/etc/firewall/’ and install the scripts “/etc/rc.d/rc.firewall”, “/usr/sbin/myfwconf” and “/var/lib/pkgtools/setup/setup.firewall”. The “myfwconf” script is the actual configurator shown in the screenshots. The “rc.firewall” script executes on boot and activates your firewall, whereas “setup.firewall” is a convenient script to be called from pkgtools:
Note that you can use the “Previous” button at any stage of the configuration to go to the previous dialog(s) and change your inputs. Pressing “Esc” at any time will bring you back to the very first dialog but then the default choice will become “No” instead of a “Yes”.
Some people report that the ISO images won’t boot when copied (using ‘cp’ or ‘dd’ for instance) to a USB stick but they all boot properly if you use the ‘iso2usb.sh‘ script provided with liveslak to transfer the ISO content to a USB stick. Of course, this will give you nice persistent storage of all your modifications with optional data encryption, ideal for a secure on-the-road Slackware environment.
All 64bit ISOs are able to boot on a computer with SecureBoot enabled. You’ll need to enroll the liveslak public key (a SSL certificate in DER encoding format with the filename ‘liveslak.der‘) into such a computer during the very first boot. That certificate file can be found in the EFI partition inside the ISO image or on the USB stick you produced. It can also be downloaded from https://download.liveslak.org/secureboot/liveslak.der if you want. This DER certificate does not change when new ISO’s are released, so an updated ISO should boot normally on your SecureBoot-enabled system using the stored version of the ‘liveslak.der’ certificate which you enrolled in the past.
I have uploaded a set of new packages for Chromium 96.0.4664.110. The package updates for chromium-ungoogled will follow shortly, they are still compiling.
This update follows on the heels of the previous one, and addresses a couple of severe/critical bugs.
This is an urgent request to upgrade your package.
You can get the chromium and chromium-ungoogled packages from slackware.nl or its mirrors.
Update (Thu Dec 16 08:13:10 UTC 2021): packages for chromium-ungoogled are updated now as well. The slackware.com server is down but you can download from slackware.nl or any mirror.
Dear visitor, you seem to be using an Ad Blocker. Please consider whitelisting 'Alien Pastures'. I use the revenue from displaying ads (small as it is) to keep this site running. Thanks!