Category Archives: Software

New handbrake and mkvtoolnix packages for Slackware 14.2 and -current

handbrake_logoI was a couple of releases behind on the Handbrake video transcoding software. I am always a bit hesitant with upgrading Handbrake. It has a history of being hard to compile on the stable Slackware releases.

Most notably it is the GTK+3 based GUI for which our Slackware libraries are often too old. And indeed, with the latest 1.3.0 release I found that this would not compile on Slackware 14.2 despite the hack I already used for the previous package (1.2..2) which I created earlier in 2019. It took me a day to come up with a second patch that allows Handbrake 1.3.0 to compile against our gtk+3 3.18.9 while in fact the program’s GUI component wants gtk+3 3.20.0 or higher.
So, Slackware 14.2 users – please tell me if you find that some functionality of the GUI is not working… it should all work properly but you never know.
In addition, I had to add a patch to make the new dav1d AV1 decoder compile on Slackware 14.2 but luckily I could just re-implement what I had already done for VLC.

The package for Slackware-current built without any glitches. Yay.

Note that my ‘handbrake‘ package does not have any external dependencies – unlike the slackbuilds.org version.
Install and run, it’s that simple. Everything you need is compiled statically into the package. The ‘HandBrakeCLI‘ program is the command-line variant, whereas ‘ghb‘ is the GUI variant of HandBrake, also found in the “Multimedia” menu of your desktop environment.

Packages for Slackware 14.2 and -current with AAC audio encoding support can be obtained from my “restricted” repository:

The variant which does not support AAC audio encoding and therefore does not violate the stupid US software patents can be downloaded from the regular repository:

 

I also have neglected my mkvtoolnix package for a while. You may be aware already that MKVToolNix is a set of tools to create, alter and inspect Matroska files (most widely known as the MKV video container format).

When working on the handbrake packages, I decided to check out the latest mkvtoolnix as well. And what do you know… the latest release won’t compile on Slackware 14.2!
I went back through the releases of 2019 and found that 38.0.0 is the most recent version which still compiles using the gcc compiler of Slackware 14.2 against the boost libraries of Slackware 14.2. Anything newer will not compile. End of the line for mkvtoolnix releases on the stable Slackware then.
These issues are absent on Slackware-current. I could compile mkvtoolnix 41.0.0 (the most recent release) easily.

Note the dependencies for mkvtoolnix:
Since its GUI and multimedia support is based on Qt5, you’ll have to install libxkbcommon and qt5 from my repository. And the qt5 dependencies as well: OpenAL and SDL_sound. On Slackware 14.2 two more even: libinput and libwacom.
Starting with mkvtoolnix 20.0.0 there’s another, new, dependency: cmark. Like with all the other dependencies I mentioned, cmark can be downloaded from my repository or any of its mirrors.
Get all the packages here:

Enjoy! Eric

LibreOffice 6.3.4 packages for Slackware-current

After a recent upgrade of the ‘boost’ package in slackware-current my LibreOffice package was in need of a refresh.
I do of course offer a ‘boost-compat‘ package in my own repository to prevent breakage of the 3rd-part applications that have a boost dependency, but a newer release of LibreOffice was available anyway.
So I compiled LibreOffice 6.3.4 for Slackware -current and uploaded these packages to my repository.

Note that the packages for LibreOffice in my repository, do contain “libreoffice-kde-integration” for Slackware -current, containing Qt5 and KDE5 (aka Plasma5) support. On the other hand, the packages I compile for Slackware 14.2 do not contain “libreoffice-kde-integration” any longer.
If you run Slackware-current but do not have KDE5 packages installed at all, don’t worry. LibreOffice will work great – the KDE integration package just will not add anything useful for you. On the other hand, if you have Plasma5 installed you will benefit from native file selection dialog windows and other integration features. And even if you do not have Plasma5 but you do have Qt5 installed, then you will be able to run LibreOffice with Qt5 User Interface elements instead of defaulting to GTK3.

If you want to compile Libreoffice 6.3.4 packages yourself using my SlackBuild, then be aware that by default the KDE5 support is disabled. You will have to set the value of the script parameter “ADD_KDE5” to “YES”. Additionally you will have to install the packages that this functionality depends on otherwise the compilation will fail.
Read the ‘README.kde5‘ file in the source directory for the list of packages you’ll need. All of them can be  found in my ‘ktown’ repository: https://slackware.nl/alien-kde/current/latest/

Enjoy! Eric

New ISOs for Slackware Live (liveslak-1.3.4)

I have uploaded a set of fresh Slackware Live Edition ISO images. They are based on the liveslak scripts version 1.3.4. The ISOs are variants of Slackware-current “Tue Dec 24 18:54:52 UTC 2019“. The PLASMA5 variant comes with my december release of ‘ktown‘ aka  KDE-5_19.12 and boots a Linux 4.5.6 kernel.

 

Download these ISO files preferably via rsync://slackware.nl/mirrors/slackware-live/ because that allows easy resume if you cannot download the file in one go.

Liveslak sources are maintained in git. The 1.3.4 release brings some note-worthy changes to the Plasma5 ISO image.

PLease be aware of the following change in the Plasma5 Live Edition. The size of the ISO kept growing with each new release. Partly because KDE’s Plasma5 ecosystem keeps expanding, and in part because I kept adding more of my own packages that also grew bigger. I had to reduce the size of that ISO to below what fits on a DVD medium.
I achieved this by removing (almost) all of my non-Plasma5 packages from the ISO.
The packages that used to be part of the ISO (the ‘alien’ and ‘alien restricted’ packages such as vlc, libreoffice, qbittorrent, calibre etc) are now separate downloads.
You can find 0060-alien-current-x86_64.sxz and 0060-alienrest-current-x86_64.sxz in the “bonus” section of the slackware-live download area. They should now be used as “addons” to a persistent USB version of Slackware Live Edition.

Refreshing the persistent USB stick with the new Plasma5 ISO

If you – like me – have a persistent USB stick with Slackware Live Edition on it and you refresh that stick with every new ISO using “iso2usb.sh -r <more parameters>”, then with the new ISO of this month you’ll suddenly be without my add-on packages.
But if you download the two sxz modules I mentioned above, and put them in the directory “/liveslak/addons/” of your USB stick, the modules will be loaded automatically when Slackware Live Edition boots and you’ll have access to all my packages again.

What was Slackware Live Edition and liveslak again?

If you want to read about what the Slackware Live Edition can do for you, check out the official landing page for the project, https://alien.slackbook.org/blog/slackware-live-edition/ or any of the articles on this blog that were published later on.

Extensive documentation on how to use and develop Slackware Live Edition (you can achieve a significant level of customization without changing a single line of script code) can be found in the Slackware Documentation Project Wiki.

Have fun!

Remote access to your VNC server via modern browsers

I think I am not the only one who runs a graphical Linux desktop environment somewhere on a server 24/7.
I hear you ask: why would anyone want that?

For me the answer is simple: I work for a company that runs Linux in its datacenters but offers only Windows 10 on its user desktops and workstations. Sometimes you need to test work related stuff on an Internet-connected Linux box. But even more importantly: when I travel, I may need access to my tools – for instance to fix issues with my repositories, my blog, my build server, or build a new package for you guys.

This article documents how I created and run such a 24/7 graphical desktop session and how I made it easily accessible from any location, without being restricted by firewalls or operating systems not under my control. For instance, my company’s firewall/proxy only allows access to HTTP(S) Internet locations; for me a browser-based access to my remote desktop is a must-have.

How to run & access a graphical Linux desktop 24/7 ?

Here’s how: we will use Apache, VNC and noVNC.

VNC or Virtual Network Computing is a way to remotely access another computer using the RFB (Remote Frame Buffer) protocol. The original VNC implementation is open source. In due time, lots of cross-platform clients and servers have been developed for most if not all operating systems. Slackware ships with an optimized implementation which makes it possible to work in a remote desktop even over low-bandwidth connections.

There’s  one thing you should know about VNC. It is a full-blown display server. Many people configure a VNC server to share their primary, physical desktop (your Linux Xserver based desktop or a MS Windows desktop) with remote VNC clients.
VNC is also how IT Help Desks sometimes offer remote assistance by taking control over your mouse, keyboard and screen.
But I want to run a VNC server ‘headless‘. This means, that my VNC server will not connect to a physical keyboard, mouse and monitor. Instead, it will offer virtual access to these peripherals. Quite similar to X.Org, which also provides what is essentially a network protocol for transmitting key-presses, mouse movements and graphics updates. VNC builds on top of X.Org and thus inherits these network protocol qualities.

Start your engines

Get a computer (or two)

First, you will have to have a spare desktop computer which does not consume too much power and which you can keep running all day without bothering the other members of your family (the cooling fans of a desktop computer in your bedroom will keep people awake).

Next, install Slackware Linux on it (any Linux distro will do; but I am biased of course). You can omit all of the KDE packages if you want. We will be running XFCE. Also install ‘tigervnc’ and ‘fltk’ packages from Slackware’s ‘extra’ directory. The tigervnc package installs both a VNC client and a VNC server.

You can store this server somewhere in a cupboard or in the attic, or in the basement: you will not have a need to access the machine locally. It does not even have to have a keyboard/mouse/monitor attached after you have finished implementing all the instructions in this article.

You may of course want to use a second computer – this one would then act as the client computer from which you will access the server.

In my LAN, the server will be configured with the hostname “darkstar.example.net”. This hostname will be used a lot in the examples and instructions below. You can of course pick and choose any hostname you like when creating your own server.
I also use the Internet domain “lalalalala.org” in the example at the end where I show how to connect to your XFCE desktop from anywhere on the Internet. I do not own that domain, it’s used for demonstrative purposes only, so be gentle with it.

Run the XFCE desktop

Let’s start a VNC server and prepare to run a XFCE graphical desktop inside.

alien@darkstar:~$ vncserver -noxstartup

You will require a password to access your desktops.

Password:
Verify:
Would you like to enter a view-only password (y/n)? n

New 'darkstar.example.net:1 (alien)' desktop is darkstar.example.net:1

Creating default config /home/alien/.vnc/config
Log file is /home/alien/.vnc/darkstar.example.net:1.log

What we did here was to allow the VNC server to create the necessary directories and files but I prevented its default behavior to start a “Twm” graphical desktop. I do not want that pre-historic desktop, I want to run XFCE.

You can check that there’s a VNC server running now on “darkstar.example.net:1”, but still without a graphical desktop environment inside. Start a VNC client and connect it to the VNC server address (highlighted in red above):

alien@darkstar:~$ vncviewer darkstar.example.net:1 

TigerVNC Viewer 64-bit v1.10.1 
Built on: 2019-12-20 22:09 
Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst) 
See https://www.tigervnc.org for information on TigerVNC.
...

The connection of the VNC client to the server was successful, but all you will see is a black screen – nothing is running inside as expected. You can exit the VNC viewer application and then kill the VNC server like this:

alien@darkstar:~$ vncserver -kill :1

The value I passed to the parameter “-kill” is “:1”. This “:1” is a pointer to your active VNC session. It’s that same “:1” which you saw in the red highlighted “darkstar.example.net:1” above. It also corresponds to a socket file in ” /tmp/.X11-unix/”. For my VNC server instance with designation “:1” the corresponding socket file is “X1”. The “kill” command above will communicate with the VNC server through that socket file.

Some more background on VNC networking follows, because it will help you understand how to configure noVNC and Apache later on.
The “:1” number does not only correspond to a socket; it translates directly to a TCP port: just add 5900 to the value behind the colon and you get the TCP port number where your VNC server is listening for client connections.
In our case, “5900 + 1” means TCP port 5901. We will use this port number later on.

If you had configured VNC server to share your physical X.Org based desktop (using the ‘x11vnc’ extension), then a VNC server would be running on “:0” meaning TCP port 5900.
And if multiple users want to run a VNC server on your computer, that is entirely possible! Every new VNC server session will get a new TCP port assigned (by default the first un-assigned TCP port above 5900).
It’s also good to know that the VNC server binds to all network interfaces, including the loop-back address. So the commands “vncviewer darkstar.example.net:1” and “vncviewer localhost:1” give identical result when you start a VNC client on the machine which is also running the VNC server.

Enough with the theory, we need that XFCE session to run! When a VNC server starts, it looks for a script file called “~/.vnc/xstartup” and executes that. This script should start your graphical desktop.

So let’s create a ‘xstartup’ script for VNC, based on Slackware’s default XFCE init script:

alien@darkstar:~$ cp /etc/X11/xinit/xinitrc.xfce ~/.vnc/xstartup
alien@darkstar:~$ vi ~/.vnc/xstartup

Edit that ‘xstartup’ script and add the following lines. They should be the first lines to be executed, so add them directly before the section “Merge in defaults and keymaps“:

vncconfig -iconic &
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS

Add the following lines immediately before the section “Start xfce Desktop Environment” to ensure that your desktop is locked from the start and no-one can hi-jack your unprotected VNC session before you have a chance to connect to it:

# Ensure that we start with a locked session:
xscreensaver -no-splash &
xscreensaver-command -lock &

In order for these commands to actually work, you may have to run “xscreensaver-demo” once, the first time you login to your desktop in VNC, and configure the screensaver properly.

Into the future

This ends the preparations. From now on, you will start your VNC server (hopefully once per reboot) with the following simple command without any parameters:

alien@darkstar:~$ vncserver

That’s it. You have a XFCE desktop running 24/7 or until you kill the VNC server. You can connect to that VNC server with a VNC client (on Slackware that’s the vncviewer program) just like I showed before, and configure your XFCE desktop to your heart’s content. You can close your VNC client at any time and reconnect to the VNC server at a later time – and in the meantime your XFCE desktop will happily keep on running undisturbed.
You can  connect to your VNC server from any computer as long as that computer has a VNC client installed and there’s a network connection between server and client.

How to make that graphical desktop available remotely ?

So now we have a VNC server running with a XFCE desktop environment inside it. You can connect to it from within the LAN using your distro’s VNC viewer application. And now we will take it to the next level: make this Linux XFCE desktop available remotely using a browser based VNC client.

We will require NoVNC software and a correctly configured Apache httpd server. Apache is part of Slackware, all we need to do is give it the proper config, but NoVNC is something we need to download and configure first.

noVNC

The noVNC software is a JavaScript based VNC client application which uses HTML5 WebSockets and Canvas elements. It requires a fairly modern browser like Chromium, Firefox, and also mobile browsers (Android and i/OS based) will work just fine.
With your browser, you connect to the noVNC client URL. Apache’s reverse proxy connects the noVNC client to a WebSocket and that WebSocket in turn connects to your VNC server port.

Some VNC servers like x11vnc and libvncserver contain the WebSockets support that noVNC needs, but our TigerVNC based server does not have WebSocket support. Therefore we will have to add a WebSockets-to-TCP proxy to our noVNC installation. Luckily, the noVNC site offers such an add-on.

Installing

Get the most recent noVNC ‘tar.gz’ archive (at the moment that is version 1.1.0) from here: https://github.com/novnc/noVNC/releases .
As root, extract the archive somewhere to your server’s hard disk, I suggest /usr/local/ :

# tar -C /usr/local -xvf noVNC-1.1.0.tar.gz
# ln -s noVNC-1.1.0 /usr/local/novnc

The symlink “/usr/local/novnc” allows you to create an Apache configuration which does not contain a version number, so that you can upgrade noVNC in future without having to reconfigure your Apache. See below for that Apache configuration.
We also need to download the WebSockets proxy implementation for noVNC:

# cd /usr/local/novnc/utils/
# git clone https://github.com/novnc/websockify websockify

Running

You will have to start the WebSockets software for noVNC as a non-root local account. That account can be your own user or a local account which you specifically use for noVNC. My suggestion is to start noVNC as your own user. That way, multiple users of your server would be able to start their own VNC session and noVNC acccess port.
I start the noVNC script in a ‘screen‘ session (the ‘screen’ application is a console analog of VNC) so that noVNC keeps running after I logoff.
Whether or not you use ‘screen‘, or ‘tmux‘, the actual commands to start noVNC are as follows (I added the output of these commands as well):

$ cd /usr/local/novnc/
$  ./utils/launch.sh --vnc localhost:5901

Warning: could not find self.pem
Using local websockify at /usr/local/novnc/utils/websockify/run
Starting webserver and WebSockets proxy on port 6080
websockify/websocket.py:30: UserWarning: no 'numpy' module, HyBi protocol will be slower
 warnings.warn("no 'numpy' module, HyBi protocol will be slower")
WebSocket server settings:
 - Listen on :6080
 - Web server. Web root: /usr/local/novnc
 - No SSL/TLS support (no cert file)
 - proxying from :6080 to localhost:5901

Navigate to this URL: 
   http://baxter.dyn.barrier.lan:6080/vnc.html?host=baxter.dyn.barrier.lan&port=6080
Press Ctrl-C to exit

I highlighted some of the output in red. It shows that I instruct noVNC (via the commandline argument “–vnc”) to connect to your VNC server which is running on localhost’s TCP port 5901 (remember that port number from earlier in the article when we started vncserver?) and the noVNC WebSockets proxy starts listening on port 6080 for client connection requests. We will use that port 6080 later on, in the Apache configuration.

From this moment on, you can already access your VNC session in a browser, using the URL provided in the command output. But this only works inside your LAN, and the connection is un-encrypted (using HTTP instead of HTTPS) and not secured (no way to control or limit access to the URL).
The next step is to configure Apache and provide the missing pieces.

Apache

Making your Apache work securely using HTTPS protocol (port 443) means you will have to get a SSL certificate for your server and configure ‘httpd’ to use that certificate. I wrote an article on this blog recently which explains how to obtain and configure a free SSL certificate for your Apache webserver. Go check that out first!

Once you have a local webserver running securely over HTTPS, let’s add a block to create a reverse proxy in Apache. If you are already running Apache and have VirtualHosts configured, then you should add the below block to any of your VirtualHost definitions. Otherwise, just add it to /etc/httpd/httpd.conf .

Alias /aliensdesktop /usr/local/novnc

# Route all HTTP traffic at /aliensdesktop to port 6080
ProxyRequests Off
ProxyVia on
ProxyAddHeaders On
ProxyPreserveHost On

<Proxy *>
    Require all granted
</Proxy>

# This will not work when you use encrypted web connections (https):
#<Location /websockify>
#     Require all granted
#     ProxyPass ws://localhost:6080/websockify
#     ProxyPassReverse ws://localhost:6080/websockify
#</Location>
# But this will:

# Enable the rewrite engine
# Requires modules: proxy rewrite proxy_http proxy_wstunnel
# In the rules/conditions, we use the following flags:
# [NC] == case-insensitve, [P] == proxy, [L] == stop rewriting
RewriteEngine On

# When websocket wants to initiate a WebSocket connection, it sends an
# "upgrade: websocket" request that should be transferred to ws://
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) ws://127.0.0.1:6080/$1 [P,L]

<Location /aliensdesktop/>
    Require all granted
    # Delivery of the web files
    ProxyPass http://localhost:6080/
    ProxyPassReverse http://localhost:6080/
</Location>

Again, I highlighted the bits in red which you can change to fit your local needs.

The “Alias” statement in the first line is needed to make our noVNC directory visible to web clients, since it is not inside the Apache DocumentRoot (which is “/srv/httpd/htdocs/” by default). I do not like having actual content inside the DocumentRoot directory tree (you never know when you accidentally create a hole and allow the bad guys access to your data) so using an Alias is a nice alternative approach.

You will probably already have noticed that Apache’s reverse proxy will connect to “localhost”. This means you can run a local firewall on the server which only exposes ports 80 and 443 for http(s) access. There is no need for direct remote access to port 6080 (novnc’s websocket) or 5901 (your vncserver).

Check your Apache configuration for syntax errors and restart the httpd if all is well:

# apachectl configtest
# /etc/rc.d/rc.httpd restart

Now if you connect a browser to https://darkstar.example.net/aliensdesktop/vnc.html and enter the following data into the connection box:

  • Host: darkstar.example.net
  • Port: 443
  • Password: the password string you defined for the VNC server
  • Token: leave empty

Then press “Connect”. You will get forwarded to your XFCE session running inside the VNC server. Probably the XFCE screen lock will be greeting you and if you enter your local account credentials, the desktop will unlock.

You can expand this Apache configuration with additional protection mechanisms. That is the power of hiding a simple application behind an Apache reverse proxy: the simple application does what it does best, and Apache takes care of all the rest, including data encryption and access control.
You could think of limiting access to the noVNC URL to certain IP addresses or domain names. or you can add a login dialog in front of the noVNC web page. Be creative.

Configure your ISP’s router

My assumption is that your LAN server is behind a DSL, fiber or other connection provided by a local Internet Service Provider (ISP). The ISP will have installed a modem/router in your home which connects your home’s internal network to the Internet.

So the final step is to ensure that the HTPS port (443) of your LAN server is accessible from the internet. For this, you will have to enable ‘port-forwarding’ on your Internet modem/router. The exact configuration will depend on your brand of router, but essentially you will have to forward port 443 on the router to port 443 on your LAN server’s IP address.

If you have been reading this far, I expect that you are serious about implementing noVNC. You should have control over an Internet domain and the Internet-facing interface of your ISP’s modem/router should be associated with a hostname in your domain. Let’s say, you own the domain “lalalalala.org” and the hostname “alien.lalalalala.org” points to the public IP address of your ISP’s modem. Then anyone outside of your home (and you too inside your home if the router is modern enough) can connect to: https://alien.lalalalala.org/aliensdesktop/vnc.html and enter the following data into the connection box in order to connect to your VNC session:

  • Host: alien.lalalalala.org
  • Port: 443
  • Password: the password string you defined for the VNC server
  • Token: leave empty

That’s it! I hope it was all clear. I love to hear your feedback. Also, if certain parts need clarification or are just not working for you, let me know in the comments section below.

Cheers, happy holidays, Eric

X-Mas Plasma5 – December ’19 release of ktown for Slackware

I uploaded KDE-5_19.12 as an early Christmas present. You can download these fresh packages as usual from my ‘ktown‘ repository. Still targeting a full installation of Slackware-current (with KDE4 removed first) these packages will not work on Slackware 14.2.

What’s new in the December 2019 release

This month’s KDE Plasma5 for Slackware contains the KDE Frameworks 5.65.0, Plasma 5.17.3 and Applications 19.12.0. All this on top of Qt 5.13.2. Do not forget to install the new packages md4c, kquickcharts, pulseaudio-qt, kpeoplevcard, and elisa !

Deps:
This month I removed the qt-gstreamer package because the only package which depended on it (telepathy-kde-call-ui) has been removed a few months back with the rest of KDE Telepathy.
I added md4c, which is a dependency for Qt 5.14 but then decided against updating my qt5 package to 5.14 because there’s a lot of software which is not completely ready for this new release of Qt. Maybe next month.
I updated the lensfun and  mlt packages to their latest releases and updated sip so that it matches the version in Slackware again.

Frameworks:
Frameworks 5.65.0 is an incremental stability release, see: https://www.kde.org/announcements/kde-frameworks-5.65.0.php but the developers added a new Framework this time: kquickcharts.

Plasma:
Plasma 5.17.3 is a an incremental bug-fix release in the 5.17 cycle of the KDE desktop environment. See https://www.kde.org/announcements/plasma-5.17.3.php

Plasma-extra;
In plasma-extra I updated latte-dock and kdeconnect-framework. The new release of kdeconnect required the addition of two new dependencies to plasma-extra: pulseaudio-qt and kpeoplevcard.

Applications;
The Releases 19.12.0 is the start of a new quarterly release cycle for the Applications, but it is also a rebranding. The old name “Applications” was no longer considered representative for what it offers and “Release Service” is the new name. I will probably keep calling this “Applications” nevertheless, tired as i usually get from overzealous PR folk.
Note that there’s a new application in here, the music player ‘elisa‘. I did not compile elisa against VLC even though that would make it more powerful. If I had installed a vlc package and compiled elisa against it, then the elisa program would fail to run for people that do do not have VLC installed. Feel free to recompile though!
For more info, see https://www.kde.org/announcements/releases/19.12/

Applications-extra:
In applications-extra I updated calligraplan, kstars and krita to their latest releases. In particular this Plan (calligraplan) release is seen as a major milestone achievement.

Telepathy:
Note: KDE Telepathy is no longer part of my ‘ktown’ distribution of KDE Plasma5.

Where to get it

Download the KDE-5_19.12 from the usual location at https://slackware.nl/alien-kde/current/latest/ or one of its mirrors like http://slackware.uk/people/alien-kde/current/latest/ (both these sites are also offering rsync access). Check out the README file in the root of the repository for detailed installation or upgrade instructions.

Development of Plasma5 is tracked in git: https://git.slackware.nl/ktown/ .
A new Plasma5 Live ISO should be ready somewhere later during my Christmas holiday (probably after Christmas) and then you will find it at https://slackware.nl/slackware-live/latest/ (rsync://slackware.nl/mirrors/slackware-live/latest/)

Have fun! Eric