Category Archives: Slackware

My Docker packages for Slackware-current

I have been using Docker for a while now, it’s being used to provide services to friends and family.
I was always intimidated by the large amount of packages that were needed to get Docker and docker-compose up and running, and I did not have experience with Docker at the time (almost two years ago) so I decided to go the easy route and use the scripts when I first needed to run a Docker container. I wrote a blog about that even, it explained how to run an Outline server to allow journalists to do their work in repressive countries but the article also shares the details how to build the Docker packages and run the daemon.

If you want to read some background information about Docker’s strength and what its use-cases are, I encourage you to start reading here: .
Essentially, Docker uses Linux kernel and filesystem capabilities to isolate an application and its dependencies from the host computer it is being executed on. Docker provides powerful means to connect multiple containers via internal (virtual) networking and can expose ports to the network outside of your container. It enables you to run applications reliably without having to worry about the underlying Operating system. You can even run Docker on a MS Windows computer but your containerized application running inside Docker will not be aware of that.
This is sometimes called ‘light-weight virtualization’ because unlike real virtualization solutions like QEMU, Virtual Box or VMWare, the containerized application still runs on your host’s kernel. This is why you can run a 32-bit container image on a 64-bit (Linux 64-bit kernel has that capability to  execute 32-bit binaries) host but you cannot run  a 64-bit image on a 32-bit host kernel.

Now that I am more familiar with Docker, have been running multiple services in containers for more than a year, and have created and published my own images (more about that later) I decided to create my own set of Docker packages. Having pre-built packages will make it a lot easier for people to start exploring the usefulness of Docker containers.

One thing upfront: I have significantly decreased the total amount of packages you need to run Docker.
I have combined the packages ‘docker’, ‘docker-cli’, ‘docker-proxy’ and ‘tini’ into a single package called ‘docker’ and also added ‘docker-buildx’ to that docker package. Also, the re-write of docker-compose from Python to Go has the benefit that the run-time package dependencies for ‘docker-compose’ have been reduced from thirteen to zero.

Starting with my Docker packages

As stated in the subject: the packages I created are for Slackware-current only. If you want to compile this yourself on Slackware 14.2, I cannot guarantee success since I did not try compiling them there myself – but in any case you’ll have to build and install libseccomp from, this is part of -current but not 14.2.

What you need from my repository to run Docker is: runc, containerd, docker and docker-compose. Four packages – that’s it.
If you want to be able to (re-)compile these packages, you will additionally need google-go-lang. After installing google-go-lang you need to logoff and login again (or run the command “source /etc/profile.d/” in your terminal) to give Google’s version of Go preference over the GCC version of Go that’s probably already installed on your computer.

The ‘docker’ package installation script will add a couple of lines to “/etc/rc.d/rc.local” and “/etc/rc.d/rc.local_shutdown” to make Docker start on boot and properly stop during shutdown of the computer. The docker rc script “/etc/rc.d/rc.docker” will initially be installed without the execute bit, so if you actually want to start using Docker you have to make the script executable. This is a one-time action. Future package upgrades will honor the executable status of that script.

# chmod +x /etc/rc.d/rc.docker

You can start the Docker daemon now if you don’t want to waste time with a reboot:

# /etc/rc.d/rc.docker start

The package installation will also trigger the creation of a new group called ‘docker’. If you want to be able to run and manage your Docker images and containers as your own non-root user account, you need to add your user account to this ‘docker’ group and then logoff/login again, and restart the docker deamon. Otherwise, all Docker operations can only be executed by the root user.

# gpasswd -a <your_useraccount> docker
# /etc/rc.d/rc.docker restart

After doing all the prep work, your account added to the ‘docker’ group and the daemon running, it’s time for a first test. Run the following command:

$ docker run hello-world

You’ll see the following output:

Unable to find image 'hello-world:latest' locally 
latest: Pulling from library/hello-world 
2db29710123e: Pull complete 
Digest: sha256:2498fce14358aa50ead0cc6c19990fc6ff866ce72aeb5546e1d59caac3d0d60f 
Status: Downloaded newer image for hello-world:latest 

Hello from Docker! 
This message shows that your installation appears to be working correctly

What you will have validated here is the proper functioning of your Docker installation:

  1. The Docker command-line client contacted the Docker daemon.
  2. The Docker daemon downloaded (or ‘pulled‘) the “hello-world” image from the Docker Hub.
  3. The Docker daemon created a new container from that image which runs the executable that produces the output you could read on your terminal just now.
  4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal.

The “hello-world” image is of course trivial, but there are many more with real-life use-cases which you can find on  Docker Hub, You can download these images freely but if you want to upload (or ‘push’) an image which you created yourself, you’ll have to create an account on Docker Hub. Free acccounts allow the creation of one single private repository and unlimited public repositories.

Slackware Docker images

I have a repository on Docker Hub where I share my base images for stable Slackware versions (that’s the 14.2 release right now). Go get them at . These “base images” are roughly 55 MB compressed, which means they are really basic. They are created using a script ( which takes its inspiration both from the liveslak scripts and of Vincent Batts‘ work on Docker images for Slackware. Essentially, the script installs some packages into a package root, uses tar to put all of that in a tarball and loads the tarfile into Docker which will then make it into an actual image for you. That image wille be called “slackware:base_x64_14.2” (unless you specified a different architecture and release of course) and that’s what I uploaded to the Docker Hub.
My tiny Slackware docker-images are not really meant to be used as-is. Instead, they can act as the foundation for Slackware-based Docker images that you might want to build yourself – any Docker image starts with some existing base image and adds new layers on top. Base images like mine above don’t inherit from a lower-level image and are a special case, read more here:

Now let’s pull that Slackware base image from the Hub and peek inside!

$ docker run -ti liveslak/slackware:latest /bin/bash -l

The “-ti” parameters tell docker to assign a pseudo-tty and run an interactive session on your terminal.
The convention for the image name is “username/imagename:tag” which shows that “liveslak” is the user who hosts the image on Docker Hub; “slackware” is the name of the image and it has a tag “latest” which means: just give me the latest version that I can get. For the slackware image, this means you get the 64-bit variant (I also have a 32-bit image) of Slackware 14.2.
The “/bin/bash -l” at the end is the command which Docker should run after bringing the container online. Remember, the base image contains nothing but a small amount of installed Slackware packages and does not start any application by itself. More complex Docker images may run all kinds of applications, some in the background and some meant to be interacted with such as the bash shell.

Running the above command yields this result:

Unable to find image 'liveslak/slackware:latest' locally 
latest: Pulling from liveslak/slackware 
6c721e5d29bd: Pull complete 
Digest: sha256:352219d8d91416519e2425a13938f94600b50cc9334fc45d56caa62f7a193748 
Status: Downloaded newer image for liveslak/slackware:latest 

And we end up at the command prompt of our running container. The container user is ‘root’, it’s the only user in that base image. You do not have to enter a password.
Let’s play a bit:

root@b0264b9e59ff:/# ls /var/log/packages/ | wc -l
root@b0264b9e59ff:/# cat /etc/os-release 
PRETTY_NAME="Slackware 14.2" 
root@b0264b9e59ff:/# exit

Suppose you want want to download and use the 32-bit Slackware 14.2 base image instead. Then you would run:

$ docker run -ti liveslak/slackware:base_ia32_14.2 /bin/bash -l

Here ends my very brief introduction to Docker on Slackware. Let me know what you think of this! Is there anything you would like to see explained in more detail?

Update 2022-jan-13: I have added packages for Slackware 14.2 (32bit and 64bit) to my repository.

LibreOffice 7.2.5 packages for Slackware-current

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

This is the fifth iteration in the 7.2 release cycle with two more to come in the next three months. Since this is a minor upgrade, the focus is on bug fixing and improving the stability.

The new packages can be found in my repository ( or any mirror if you wait a day, for instance .

Enjoy the new release – Eric

Chromium 97 added to my repository; fixes a critical vulnerability

A couple of days ago Google released the sources for Chromium 97.0.4692.71. I am still waiting for an update to the chromium-ungoogled sources but I have already uploaded Slackware packages for chromium (targeting 14.2 and -current) to my repository.

This release addresses one ‘critical’ vulnerability (CVE-2022-0096, ‘Use after free in Storage‘) and brings a total of 37 security fixes. From a user perspective, I could not find particularly exciting new functionality in the release notes. The security fixes still make this a recommended upgrade.

You can get my chromium packages from or its mirrors.


Update 08-jan-2022: packages for chromium-ungoogled 97.0.4692.71 are now also available in my repository.

Repository purge coming up soon-ish

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:

And also these:

I will leave the multilib repositories ( and its mirrors) untouched.


I finally updated my avidemux package

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

In the midst of a full week of holidays and waiting for my rye/honey sourdough bread dough to ferment, I had plenty time to devote to the creation of a fresh package for  Avidemux 2.8.0. This was recently released; yesterday actually!
And not just avidemux needed some work on its SlackBuild script; I needed to update ageing scripts for aften, faac, faad2, libdca, libfdk-aac, opencore-amr, x264 and xvidcore, and added a x265 package before I could compile avidemux with full support for codecs and plugins.

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.

In case you are interested in some comparisons between the functionality of Avidemux and its competitors, here are some pointers. In terms of video conversion capability it compares to Handbrake (also in my repository), see here: When you look at its video cutting and edting qualities on the other hand, Avidemux is better compared with Kdenlive which is included in Slackware as part of KDE Plasma5:

FYI… my sourdough bread is out of the oven, and it’s smelling great!