My thoughts on Slackware, life and everything

Tag: git (Page 1 of 2)

Using the Slackware Community Forge

I wanted to share some news with you. After weeks of hard work and being forced to learn new tech from scratch, the Slackware Community Forge, a git software forge, is now available at https://forge.slackware.nl/ .
It’s not just a git repository server but also a Docker container registry!

 

What the Forge?

I created this Forge as an autonomous and European based alternative to the popular git forges like Github and Gitlab. I have  (well not only I, but a lot of people have) issues with the fact that Github is owned by Microsoft, is fully proprietary and enforces the Microsoft CoPilot AI in weird and unacceptible ways (even though it was ‘by accident’, the tendency and the intent is clear). And Gitlab recently moved office to the US which makes them subjugated to the US administration. Also, Gitlab recently announced their commitment to AI and at the same time will fire 30% of their workforce because of it.
The Slackware  Community Forge is not connected to any form of AI, and it is powered by Forgejo, a fully open source software governed by a European company. meant to be used for hosting free, Open Source and Open Standards Software (OSOSS).

I am not principally opposed to US based companies and their software.  I worked at IBM, use software from Red Hat and my friend Patrick Volkerding runs the US based Slackware Linux company. But I do have concerns about the dangers of potentially having my data controlled by US based entities. Even if my data is encrypted so that content cannot be accessed, the US administration can still request that my own access to my own data is revoked.
My Slackware Cloud Server series of articles is meant to help you (individuals, groups, communities or companies) to implement self-hosted variants of online services that are under your own control, to prevent the risk of losing access to your data, or having your data being monetized by training AI models or by selling it to advertisement platforms.
I invite you to also read those articles!

Now, the Forge.

The Slackware Community Forge is a web-based familiar  interface to manage your own git repositories, use CI/CD runners to validate the changes to your code. The site offers workflows to generate release tarballs. There’s also command-line access via SSH connections using SSH keys.

The CI/CD workflows make use of Slackware Docker images. They are available for stable Slackware release 15.0 and for -current at the time of writing this. Those images come in both 32bit and 64bit flavors. The Slackware Docker images are kept up to date with the changes in Slackware: the images are automatically re-generated when an update to the Slackware ChangeLog.txt is detected.

Of course you can download and use these Docker images locally, the Docker registry is public and does not require an account to download from. For the Slackware “base” images which are really small, the registry URL is https://forge.slackware.nl/slackware/-/packages/container/slackware/versions . The Forge also offers Slackware “builder” images of nearly 2 GB in size, offering all the build tools you would need to compile your project; their registry URL is https://forge.slackware.nl/slackware/-/packages/container/slackware-builder/versions .

If you access the registry via Docker, the hostnames ‘forge.slackware.nl‘ and ‘registry.slackware.nl‘ will both work.

As an example, if you have Docker installed and want to test the image for 64bit Slackware-current, you can run:
$ docker run --rm registry.slackware.nl/slackware/slackware:current bash -c "cat /etc/os-release"
...
Unable to find image 'registry.slackware.nl/slackware/slackware:current' locally
current: Pulling from slackware/slackware
Digest: sha256:74a1caaababd145d40196ee29207c8c0a10602f39463a5077ea1bbe9f05a54d6
Status: Downloaded newer image for registry.slackware.nl/slackware/slackware:current
NAME=Slackware
VERSION="15.0"
ID=slackware
VERSION_ID=15.0
PRETTY_NAME="Slackware 15.0 x86_64 (post 15.0 -current)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:slackware:slackware_linux:15.0"
HOME_URL="http://slackware.com/"
SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/"
VERSION_CODENAME=current

The Slackware Community Forge accepts users and organizations that have a relationship to the Slackware ecosystem. If you work on a project that matters to Slackware users, or users of Slackware derivatives, you are invited to request an account. Send an email to forge@slackware.nl from the email address that you want to have associated with your Forge account. I will also need your First and Lastname and the login userID that you want to use.
I will send you the temporary password in reply.

Once you receive your credentials, browse to https://forge.slackware.nl/ and click “Sign In”.
On the sign-in page, click “Sign in with Keycloak”:

This will redirect to the Keycloak server which is the Identity Provider that handles the Single Sign On for Slackware Community Services:

Once you enter your userid and the temporary password you received. you are asked to create a new permanent password.
When the login is complete and you have memorized your new password, you will be directed back from Keycloak to the Forge. There you will be asked whether you want to register a new account or link your account to an existing local account.
Your account only exists in Keycloak, so you select “Register new account” and then Forgejo will create an account in its own database which it will link to your actual Keycloak identity:

You are now ready to start using the Forge in earnest.

Pushing your commits to your repository

Your account lives in the Keycloak Identity Provider (IP). Forgejo’s web interface offers the “Sign in with keycloak” button but when you push your commits to your repository via the commandline interface or via https, Forgejo will not recognize your credentials (it will only recognize local accounts). This is a fundamental aspect of how OIDC authentication works in Forgejo, and it cannot be “fixed” to make Keycloak passwords work for “git push”. This is by design. The OIDC flow requires a browser redirect. There is no way to retrofit it into a non-interactive git credential prompt.
There’s two solutions to this issue:

1: Add a SSH key to your Forge account.

This is recommended for any developer doing regular git work and who wants to access their repositories over a SSH connection.
Assuming that you already have a SSH public/private key pair on your computer called “/home/your_username/.ssh/id_ecdsa_forgejo” that you want to use with the Forge, add that public key in Forgejo:

  • ‘Settings > SSH / GPG keys > Manage SSH keys’ (or browse directly to https://forge.slackware.nl/user/settings/keys)
  • Click ‘Add key’
  • Copy the ASCII text of your public key into the provided field that says:
    Begins with “ssh-ed25519”, “ssh-rsa”, “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”, “sk-ecdsa-sha2-nistp256@openssh.com”, or “sk-ssh-ed25519@openssh.com”
  • Give your key a name so that you can recognize it when you add more
  • Click ‘Add key’ again.

Then on your local computer:

  • Add  the following lines to your ~/.ssh.config file (create the file if it does not yet exist and do a “chmod 600” on the file or else ssh will simply refuse to use it):
Host forge.slackware.nl
  Port 2222
  User git
  ServerAliveInterval 20
  IdentityFile /home/your_username/.ssh/id_ecdsa_forgejo
  • Change directory to the clone of your remote repository, and add the remote as follows (it’s a one-time setup, works forever, for all your repositories, and there are no passwords involved at all.):
$ git remote set-url origin forge.slackware.nl:your_username/your_repository.git

All you need to do to push your commits to the remote repository is a:

$ git push origin

No credentials need to be entered at all.
And if this is the first time you connect to the Forge via SSH, you need to accept its SSH server key to continue. This is also a one-time action.

2: Forgejo API token

This works well for  HTTPS workflows or in environments where SSH is blocked. The API token (aka Access token) takes the place of a regular password.
If you had already cloned your repository, the “origin” URL definition in the “.git/config” file inside that repository will look like this:

[remote "origin"]
    url = https://forge.slackware.nl/your_username/your_repository.git
    fetch = +refs/heads/*:refs/remotes/origin/*

You generate an API token as follows:

  • Login to Forgejo
  • Go to ‘Settings > Applications > Access token’ (or go directly to https://forge.slackware.nl/user/settings/applications)
  • Click ‘New access token’
  • Give the token a descriptive name, make it access to ‘All’
  • Select the permissions you want this token to have; at least that should be:
    • Repository: “read and write”
  • Click ‘generate token’
  • Copy and store the token string in a safe place; this token string can not be retrieved later. If you forget it, you can simply create a new token and use that instead.

Then use the token as the password for HTTPS connections:

$ git push origin
Username for 'https://forge.slackware.nl': your_username
Password for 'https://your_username@forge.slackware.nl':
Everything up-to-date

At the “Username” prompt enter your Forgejo username, and at the “Password” prompt enter your API token.

To avoid typing the API token every time, you can store it in git’s credential helper:

$ git config --global credential.helper store

Then do one successful push. Your credentials are saved to the file ~/.git-credentials with mode ‘0600’ which means that only you can read the contents, which look like this:

https://your_username:APITOKEN@forge.slackware.nl

Documentation

In the “forge-docs” repository of the Slackware organization in Forge, you can find:

Finally…

I hope you will appreciate this new service and also start migrating your Github / Gitlab repositories to the Slackware Community Forge.
Try the CI workflows and report any issues you encounter! Note that I am the single administrator and moderator. Be gentle.

 

My commitment is to run this Forge as a stable and long-term service to the Slackware community. I’ve written admin documentation and in time will look for more administrators. Let’s first see if this initiative is going to be used at all 😉

Have fun! Eric

Ktown updates: KDE Frameworks and Gear (PIM & Applications)

Today KDE Frameworks 6.22.0 were released, and yesterday we already saw new KDE Gear 25.12.1 tarballs.
Note – in ‘ktown’ you will find that KDE Gear packages are split over ‘kdepim’ and ‘applications’.

I built new packages for those new sources and now you can get the packages for 32bit and 64bit Slackware from the original server: https://slackware.nl/alien-kde/current/testing/ or else from one of its mirrors.
For US folk, this one already has all the new packages: https://us.slackware.nl/alien-kde/current/testing/ .

You can download the sources from https://slackware.nl/alien-kde/source/testing/ and if you want to track the changes in git, go visit https://git.slackware.nl/ktown/log/?h=6_26.01

Have fun! Eric

KDE Plasma 6_25.12 for Slackware-current

A couple of days ago, I promised to use my holiday to come up with packages for KDE Plasma6.
Today I finished compiling packages for 32bit and 64bit Slackware-current and uploaded a fresh package repository to my ‘ktown‘. The name seems to stick with people, even when it has not seen activity for two years, so I will keep calling it ‘ktown‘.

You will find these packages at the origin location: https://slackware.nl/alien-kde/current/testing/ together with an expansive README which will help you remove KDE Plasma5 from your Slackware-current computer and install the ‘ktown‘ version of KDE Plasma6 instead.

I just went through the process and this is the first time that I am actually running and using KDE Plasma6 on my production laptop:

I did not have to remove any kind of configuration from $HOME and merely had to delete a couple of obsoleted system tray elements.

I also switched to Wayland instead of X11 and to be honest, that is working better than expected and even better than the good old X11 session. For instance, suddenly I can play 4K video in VLC without stuttering. And the laptop’s  Synaptics touchpad was not found at all in the X11 session (must be a bug because I had been using it for 9 years in Slackware KDE)… while it works perfectly in the Wayland session.
The thing that I miss is the Latte Dock which was dropped from KDE Plasma. Having these MacOS-like ballooning application launcher icons floating at the bottom of my screen always impressed my friends, but it was also extremely powerful in the way I could manage my favorite applications. In Plasma6 I created an auto-hiding QuickLaunch panel at the bottom of the screen but it looks dull compared with the Latte Dock. Shame.

My intention is to keep this new Plasma6 package repository in a ‘testing‘ state as reflected in the repository URL. I expect that there’s stuff that does not work as it should and I would like you all to help in testing and stabilizing the packages. When KDE Gear 26.04 releases in April 2026 I expect that the few remaining Qt5 based KDE applications will finally have been ported to Qt6. By that time, I want to promote the repository from ‘testing‘ to ‘latest‘ and that will then reflect in the repository URL.

If you would look at the content behind the ‘latest‘ repository right now (https://slackware.nl/alien-kde/current/latest/) you will see that it is pointing to a single left-over package for KDE Plasma5 (Slackware 15.0): ‘phonon-vlc‘, a backend for Phonon that requires VLC media player. By the way, I renamed that package to ‘phonon-backend-vlc‘ for Plasma6 to be in line with the Slackware naming convention for these backends.
In April 2026 that repository will get a new  ‘stable’ URL to reflect that it is meant for the stable release of Slackware.

If you want to peek at the source code management, I track everything in a git repository. You will find the 6_25.12 branch at: https://git.slackware.nl/ktown/
A word of thanks to LuckyCyborg who maintained a fork of my ‘ktown‘ during 2024/2025. He never contacted me about this but I was made aware of his activities. I checked out his scripts last week and there were some improvements he came up with that I have incorporated into my own sources. See the git commit message for more details.

I suggest that you try these Plasma6 packages out yourselves! Please leave your feedback in the comments section below.

Enjoy the end-of-year festivities and all the best for 2026! Let’s hope that Slackware merges Plasma6 before the end of 2026.
Cheers, Eric

How I setup cgit for a browsable liveslak repository

I received a request to document how I configured the backend for https://git.liveslak.org/ . This is where my git repository for liveslak is accessible and browseable using cgit as the engine.
Of course the server is also running an actual git repository service which people use to clone the liveslak files and for me to upload changes.
Setting up git is not hard, but it’s beyond the scope of this blog article. Also, setting up Let’s Encrypt to create a secure (https) web site is not in the scope of this article but you can read my Let’s Encrypt article of course.

I’ll explain the steps that are needed to create a cgit webserver in the text below.
First we build and install cgit as well as its dependencies; then we create the cgit configuration and add some customization. Lastly we configure Apache httpd so that it knows what to serve.

Let’s start with building the required packages in order. In case you are running Slackware -current (i.e. newer than 15.0) then the lua package is already included in the core distro, so you can skip compiling it now:

  • lua
  • luacrypto
  • lua-md5
  • highlight
  • cgit

You can find build scripts for all of them on the SlackBuilds.org (SBo) web site.
The lua* and highlight packages are needed for syntax highlighting, and lua is also needed for gravatar support.
The cgit package has customization added by the SBo admins which we are going to use, notably support for displaying the committers’ gravatar images.

Once you have built and installed the above packages, create a new directory to hold our custom cgit stuff:

# mkdir -p /home/www/cgit

Create some symlinks to the files that were installed by the Slackware cgit package:

# ln -s /var/www/cgi-bin/cgit.cgi /home/www/cgit/
# ln -s /var/www/cgi-bin/cgit.js /home/www/cgit/
# ln -s /var/www/cgi-bin/cgit.png /home/www/cgit/

But make a copy, not a symlink, of the CSS file:

# cp -ia /var/www/cgi-bin/cgit.css /home/www/cgit/

Some additional CSS code needs to be added to cgit.css to make the committer avatars hover properly. Here’s the lines to append to the file copy we just made (you will find this same code in the file /usr/doc/cgit-*/email-gravatar-sbo-additions.css which is part of the Slackware cgit package):

div#cgit span.gravatar img.onhover {
    display: none;
    border: 1px solid gray;
    padding: 0px;
    -webkit-border-radius: 4px;
    -moz-border-radius: 4px;
    border-radius: 4px;
    width: 128px;
    height: 128px;
}
div#cgit span.gravatar img.inline {
    -webkit-border-radius: 3px;
    -moz-border-radius: 3px;
    border-radius: 3px;
    width: 13px;
    height: 13px;
    margin-right: 0.2em;
    opacity: 0.8;
}
div#cgit span.gravatar:hover > img.onhover {
    display: block;
    position: absolute;
    margin-left: 1.5em;
    background-color: #eeeeee;
    box-shadow: 5px 5px 3px #bbb;
}

We also need to tweak the syntax-highlighting.sh script (part of the cgit package) a bit so it works better for us Slackers.
Make a copy of it, removing all comments:

# grep -Ev '(#$|^ *#)' /usr/share/cgit/filters/syntax-highlighting.sh > /home/www/cgit/syntax-highlighting.sh
# chmod +x /home/www/cgit/syntax-highlighting.sh

And then add these lines right before the final ‘exec’ line of the script:

# map SlackBuild to .sh
[ "$EXTENSION" == "SlackBuild" ] && EXTENSION=sh

To make the git.liveslak.org website stand out from others, I substituted my own frontpage image and a custom favicon image. These are created as /home/www/cgit/eric_hameleers.png (link) and /home/www/cgit/erichameleers_favicon.ico (link) and both filenames are referenced further down in the cgit configuration.
By default, cgit will look for a file called “/etc/cgitrc” to read its configuration, but I am running multiple sites on a single Slackware host (git.slackware.nl for instance), therefore I create a separate cgit configuration file for each site. For liveslak, it is called “/etc/cgitrc.git.liveslak.org” and then I instruct Apache httpd to look for that particular filename.

/etc/cgitrc.git.liveslak.org

# For more options, see cgitrc.5.txt in the docs folder
root-title=Alien BOB's
root-desc=Web interface to liveslak git repository
virtual-root=/
snapshots=tar.gz tar.xz

summary-branches=10
summary-log=10
summary-tags=10

repository-sort=date
commit-sort=date
branch-sort=age

enable-blame=1
enable-index-links=1
enable-commit-graph=1
enable-follow-links=1
enable-log-filecount=1
enable-log-linecount=1
max-stats=quarter

mimetype-file=/etc/httpd/mime.types
mimetype.rss=application/rss+xml
enable-html-serving=1

css=/cgit.css
logo=/eric_hameleers.png
favicon=/erichameleers_favicon.ico

about-filter=/usr/share/cgit/filters/about-formatting.sh

# for this to work you have to build cgit against lua
# and install luacrypto too
email-filter=lua:/usr/share/cgit/filters/email-gravatar-sbo.lua

# For this to work, you need lua and highlight packages:
source-filter=/home/www/cgit/syntax-highlighting.sh

repo.url=liveslak
repo.path=/path/to/repositories/liveslak.git
repo.desc=Slackware Live Edition by AlienBOB
repo.owner=alien@slackware.com
repo.clone-url=git://liveslak.org/liveslak.git
repo.readme=:README.txt

The actual definition for the git repository is the lines at the end starting with “repo.“.

Lastly, the Apache web server needs to be configured to serve our cgit stuff whenever someone visits git.liveslak.org.
These are the files used to accomplish that:

/etc/httpd/extra/git.liveslak.org.conf

(just an example filename, you will know how and where to add the content for your specific Apache configuration):

<VirtualHost *:80>
    ServerName git.liveslak.org
    ServerAdmin alien@slackware.com

    CustomLog /var/log/httpd/git.liveslak.org_access_log combined
    ErrorLog /var/log/httpd/git.liveslak.org_error_log

    # Include Let's Encrypt configuration:
    Include /etc/httpd/extra/letsencrypt.conf

    # Include the site definition (AFTER Let's Encrypt configuration!!):
    Include /etc/httpd/extra/git.liveslak.org_content.conf
</VirtualHost>
<VirtualHost *:443>
    ServerName git.liveslak.org
    ServerAdmin alien@slackware.com

    CustomLog /var/log/httpd/git.liveslak.org-ssl_access_log combined
    ErrorLog /var/log/httpd/git.liveslak.org-ssl_error_log

    # Include Let's Encrypt configuration:
    Include /etc/httpd/extra/letsencrypt.conf

    # Include web server generic SSL configuration for vhosts:
    Include /etc/httpd/extra/ssl_vhost.conf

    # Include the site definition (AFTER Let's Encrypt configuration!!):
    Include /etc/httpd/extra/git.liveslak.org_content.conf
</VirtualHost>

The file “git.liveslak.org_content.conf” is included twice in the above VirtualHost definition file for Apache. Using these “Include” lines prevents some duplication of code.
Here is the content of that included file:

/etc/httpd/extra/git.liveslak.org_content.conf

DocumentRoot /home/www/cgit
Options FollowSymlinks

# Use a custom name for the configuration - default is /etc/cgitrc:
SetEnv CGIT_CONFIG /etc/cgitrc.git.liveslak.org

DirectoryIndex cgit.cgi
AllowOverride none
Require all granted

SetHandler cgi-script

Options ExecCGI
Require all granted

Alias /cgit.css /home/www/cgit/cgit.css
Alias /cgit.png /home/www/cgit/cgit.png
Alias /erichameleers_favicon.ico /home/www/cgit/erichameleers_favicon.ico
Alias /eric_hameleers.png /home/www/cgit/eric_hameleers.png
Alias /robots.txt /home/www/cgit/robots.txt
Alias / /home/www/cgit/cgit.cgi/

I hope that this story may help some of you with getting your own browseable git repository online.

Good luck, Eric

Liveslak 1.8.0 – more filesystems supported, lots of fixes

Liveslak updates! Quite soon after my August ISO refresh, I used some free moments to implement a request of sorts and fix some longstanding bugs.
Version 1.8.0 of the liveslak scripts is now available, containing these enhancements and fixes.
Links to the liveslak git repository and download locations are at the bottom of this post. Of course, the new functionality and fixes are also present in a fresh batch of Slackware Live ISO images.

New features of liveslak 1.8.0

  • LUKS encrypted containers for your homedirectory and for persistence are now supporting many more filesystems, not just ext2/4 but also btrfs, f2fs, jfs or xfs. The lack of f2fs support was mentioned by a visitor of this blog and I thought that was useful feedback.
    The accompanying scripts iso2usb.sh and isocomp.sh now support this filesystem choice via a new ‘-F‘ switch.
    Note that the Linux partition of a USB Live thumbdrive remains ext4 formatted, because liveslak uses extlinux to boot on a BIOS computer.
  • The upslak.sh script can now extend the size of the  LUKS encrypted container files on your USB thumbdrive, in case you run out of storage there.
  • I fixed the pxeserver script and expanded its functionality:
    • PXE boot of a UEFI computer finally works.
      Note that this may not work for you out of the box, because there are two implementations in dnsmasq to support UEFI PXE boot… and sometimes, one will work and the other won’t. So, you may have to open the /usr/local/sbin/pxeserver script in an editor and look for the section where a number of ‘dhcp-match‘ and ‘dhcp-boot‘ lines is commented out. If you remove the comment characters from these 8 lines and instead, add a comment character ‘#’ in front of the ‘dhcp-match‘ and ‘pxe-service‘ lines a bit higher up, your UEFI computer might actually succeed in booting over the network.
    • NAT firewalling can be optionally enabled in case PXE clients wouldn’t have Internet access otherwise.
  • I fixed the hang during shutdown/reboot when liveslak is a PXE client.
  • I fixed UEFI boot using GRUB when the live ISO had been ‘dd’-ed or ‘cp’-ed directly to a USB thumbdrive. You would end at the GRUB prompt instead of booting into the OS.
    It took me quite a while because this bug was introduced in Feb 2019 (!), and I never found the time to investigate. Eventually looking into it during a weekend of solitude caused an epiphany.
  • I added support for a dark theme in KDE Plasma based ISOs, with the LEAN ISO as an example (that one also gets a new login/desktop background image taken from my photo collection with every ISO refresh).
  • Lots of other small fixes and enhancements, read the Git log for more information.

Booting from an on-disk ISO file

Liveslak supports Ventoy, a multi-boot manager for removable media like USB thumbdrives which lets you boot any ISO image you store on the disk, selecting from a GRUB menu it creates on the fly.
Because liveslak  implements the “Ventoy-compatible” guideline, any Slackware Live ISO works out of the box on Ventoy. Support for encrypted persistence and homedirectory containers on a Ventoy disk is offered by the ISO companion script ‘isocomp.sh‘.
You can find the details in the git commit message.

Install Slackware using a liveslak ISO

A quick reminder that you can use a liveslak ISO to install Slackware to your hard drive from its official package repository (using a network installation from a HTTP, FTP, NFS or Samba server).
You can also install the actual content of the Live ISO to your harddisk if you like. In this case all “live aspects” will be skipped during the copy, so that you will in fact end up with a completely regular Slackware on your harddisk.
The program to run these installations is available on all liveslak ISOs and is called ‘setup2hd‘. It is derived from the ‘setup‘ program of a Slackware install media, but has some nice enhancements: it launches cfdisk/cgdisk for you to partition your disks, lets you create a regular user, and allows you to configure a basic firewall.
Best of all, you can run setup2hd in an X-terminal and let the installer chomp through the packages while you browse the internet, watch a video or perform any other kind of leisurely activities on your Live OS.

And by the way: booting Slackware Live is the only way (using setup2hd) to install the official Slackware distro from a network server across a wireless connection. The official Slackware installer only supports wired network connections.

Get liveslak ISOs

The various variants of Slackware Live Edition can be found in the “latest” subdirectory at https://download.liveslak.org/ or its US mirror https://us.liveslak.org/ . A fast UK mirror is provided by Darren Austin at https://slackware.uk/liveslak/ .
You’ll be able to download ISO Live images of 32bit and 64bit Slackware proper, also of the small XFCE variant for (both architectures), and then CINNAMON, DAW, LEAN and MATE ISOs that only come in 64bits.
Big thanks to Willy Sudiarto Raharjo (willysr) for maintaining the Mate and Cinnamon Slackware package repositories.
Also have a look in the “bonus” subdirectory! There you’ll find Nvidia graphics and Broadcom wireless binary drivers, Wine 8 and multilib modules to add if you use the persistent version of liveslak.

All ISOs containing a 64bit Live Slackware have support for SecureBoot.

Get liveslak sources

The liveslak project is hosted in git. Its browsable cgit interface is here: https://git.liveslak.org/liveslak/

A set of the liveslak scripts can also be downloaded from http://www.slackware.com/~alien/liveslak/ or https://slackware.nl/people/alien/liveslak/

Have fun! Eric

« Older posts

© 2026 Alien Pastures

Theme by Anders NorenUp ↑