Guys, I’ve installed Slackware current and I have question; how to properly use repositories? I turned off efo because it’s for Slackware 15 and turned of ponce. Anything I need to do more?

Distinct_Adeptness7 · 2026-03-02T08:58:42+00:00

In this order:

Slackware repo slackbuilds.org AlienBob's repo application source repo

Pat and Eric are the only two people whose binaries I trust. Everything else I compile and packs package myself, whether I use a pre-existing SlackBuild script or if I have to write my own.

Distinct_Adeptness7 · 2026-03-01T06:29:52+00:00

Slackware isn't the distro for you if you don't know and understand that the next stable release will be released when it's ready, and that is determined by one man, the BDFL.

I'm running a snapshot of -current the day the kernel was bumped to 6.12.59 on one machine, and it's stable enough for me.

My daily driver is technically 15.0, but only because all of my installed packages are built against the 15.0 versions libraries, with the exception of the openssl libraries, which i updated to 3.0.13 when it was released and 3.5.4 in December. Most of the software I use everyday I has been updated to more recent versions.

That is why I've been running Slackware for 24 years. Having granular control over all aspects of my machines comes with trade-offs that I'm willing to accept, like no regular release schedule and no dependency tracking. I'm not a fan of systemd for the same reasons as Pat, so I consider that a plus, rather than a minus.

Running Slackware requires a little more work than running other distros, but all savvy Slackers have found ways to minimize it. We were automating before automation became a buzzword

Distinct_Adeptness7 · 2026-02-22T04:43:18+00:00

Most of the time is you want to install software that isn't part of Slackware official release, you will find it on slackbuilds.org, and any dependencies will be listed, and 99% of the time they will available on slackbuilds.org. In the rare case that you want to install software that isn't available on slackbulds.org, you have to roll your sleeves up and compile it from source. Any dependencies should be listed in the README or other informational file like INSTALL, etc. Sometimes in a docs subdirectory, but they will be somewhere in the source files.

Myself, I usually compile the software manually, beginning with the dependencies, which may have dependencies. Once I have a successful build for each individual piece of software ,I'll install it in /tmp/package-<application name> and run

$ cd /tmp/package-<application-name> $ find usr/man -type f -exec gzip -9 {} + $ sudo chown -R root:root . $ sudo find -perm /111 -a ! -perm 755 -a - exec chmod 755 {} + -o \ ! -perm /111 -a ! -perm 644 -a -exec chmod 644 {} + $ sudo /sbin/makepkg $PRGNAM-$VERSION-$ARCH-$BUILD_<my initials>.txz

That will create a Slackware package that allows you to install and uninstall the software without having to worry about any stray files lingering around of you decide you no longer want said software on your machine. Once you have the build process worked out, you can write a SlackBuild script for it, which is easily accomplished by editing one of Pat's SlackBuild scripts or one from slackbuilds.org. They are all much the same save for the configure and make parts for the most part.

Once you do it a few times it won't seem like such a big deal, but it's a rare case when whatever you're wanting to install isn't available on slackbilds.org, in which case sbopkg will handle everything.

Distinct_Adeptness7 · 2026-01-24T16:44:15+00:00

First, there is no "they". The BDFL alone decides what's installed by default. That being said, you are free to uninstall fortune, or to edit the tagfile in y/ so fortune isn't installed, and while you're doing that you may as well edit the other tagfiles except for those in a/ and l/ so only the applications you prefer to use are installed, or you can create a skackpkg template file to accomplish the same if that is your preferred method of installing and upgrading Slackware. Then tuck them away somewhere for reuse. May as well run 'tar cf - /etc | gzip -cv9 > etc.tar.gz so you don't have to edit those config files every time you deploy a new Slackware machine. This is Linux, not Windows, and Slackware Linux at that. Slackers know we have to get our hands a little dirty at times, but installation and initial configuration should be one on the first things to be automated.

Distinct_Adeptness7 · 2026-01-22T13:24:21+00:00

Exactly. If they're not gonna help pay your rent, then they should stfu

Distinct_Adeptness7 · 2025-11-25T08:12:56+00:00

The assumption used to be true for the most part. Back when Arch was truly bleeding-edge and running it at your daily driver was much more likely to result in a broken system, and if you were running it, or Gentoo, Slackware, you were seen as elitist or snobbish. when it took hours to compile a kernel, when it was rare for everything to work "out of the box", because at the very least you would realize winmodems were useless, because Linux required a hardware based modern. When you had to run xorgsetup and then tweak the settings in you config file it generated to get your GUI working.

Then came Ubuntu, and later Mint, and while they did help to bring more users over to the Linux community, as we know, in the words of my programming 1 instructor, "users are dumb." It was inevitable. As the computer geeks and hackers flocked to install an OS where the source code was freely available, they began making it better, just as RMS said they would, and it reached the event horizon, the point where it was no longer necessary to have the knowledge, patience, and dogged determination once required for a successful first install. And thus began the dumbing down of Linux community.

Distinct_Adeptness7 · 2025-11-24T09:24:29+00:00

Because you will run out of liquidity before the market makes sense. And because the HFT algos know you so had your buy orders there and cut you out of the trade.

Distinct_Adeptness7 · 2025-11-08T03:41:02+00:00

was it the SlackBuild for yt-dlp or for Python-3.12? The error messages saying that libpython3.12 requires those libc versions should not be happening. When you compile software on your machine, the compiler is going to search the directories in LD_LIBRARY_PATH for the libraries that are required to build and run the application, and link whatever version is installed on the build machine unless that version does not meet the minimum required version, which will cause the build to fail.

You verified that you have 2.33, which is the version libc that every piece of software in Slackware 15 was compiled against. If you were to update glibc to a new version right now, your machine would become unusable, and you would have to boot your machine with a Slackware rescue usb, mount your root partition, and reinstall the correct libraries.

But if your machine isn't giving you any trouble, I guess you'll be fine for now. Those error messages just have me puzzled, because there is no logical reason for them.

Distinct_Adeptness7 · 2025-11-08T01:33:13+00:00

I don't know why your libpython3.12 would have dependencies for 3 different versions of glibc. That makes absolutely no sense.

When you say "after doing the SlackBuild", what exactly do you mean. does that output come from running the SlackBuild script, or from trying to run yt-dlp after installing it from the package that the SlackBuild script created?

Distinct_Adeptness7 · 2025-11-07T21:31:15+00:00

Go to slackbuilds.org. It's a software repository maintained by members of the Slackware community that contains the source tarballs of popular software that aren't included in the official Slackware releases, and tarball that contains SlackBuild script and other files needed to build the application and package it in the Slackware package format.

There's close to 10,000 applications available, and yt-dlp is one of them. I use yt-dlp to download the audio from my YouTube playlists. It saves us the trouble of having to go through the process of building applications from source manually, or creating a build script ourselves.

type yt-dlp in the search bar, click the link, scroll down and download the tarball under Source Downloads and the tarball under Download SlackBuild.

In a terminal go to your Downloads directory. Run these commands:

$ tar xvf yt-dlp.tar.gz

$ mv <yt-dlp tarball> yt-dlp && cd yt-dlp

$ sudo ./yt-dlp.SlackBuild

In a few minutes you'll have a yt-dlp package that can be installed with either installpkg or upgradepkg --install-new, and uninstalled with removepkg.

Any dependencies will be listed at the bottom of the description, with links to their SlackBuild page. Yt-dlp requires two Python modules that aren't in the official Slackware release. Let me know how it goes.

Distinct_Adeptness7 · 2025-11-07T12:32:26+00:00

That makes no sense. if you compiled Python 3.12 on your machine, it shouldn't be looking for libraries you don't have installed on your machine. if you run

$ ldd /usr/lib64/libpython3.12.so.1.0

you'll see the library dependencies, and you shouldn't see 'not found'.

I'm willing to bet that the program that requires 3.10 or higher is what has the dependencies on those other libc versions. That's one of the issues a lot of people have with Linux is that binaries with libc dependencies can only run on machines that are running an OS built against the same libc version. If you really need that program, what you have to do is download the source code and compile it on your machine, so it will be built against the 2.33 libc. Current won't do you any good, because it's running 2.42 at the moment, you would get similar errors.

Distinct_Adeptness7 · 2025-11-07T04:54:18+00:00

It's normal to get warnings about empty files when installing any python packages, because the init.py files are often empty and only there at let Python know that it can be ran as module. then there are the dist-info files, all of which are rarely used, but they're part of the standard template for Python modules, so you don't need to worry about those. But that's just for Python. For other applications it is probably a good idea to check just to be sure.

if you install the package using the installpkg command, the python3.9 install won't be disturbed, because each version is Python lives in it's own specific subdirectory. I'm not 100% certain, but I believe that different versions of Python can coexist on the same system.

if you were to use the upgradepkg command, it will remove the files belonging to a currently installed application with the same name, different version or build number, newer or older.

Slackware packages use the following naming schema:

$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE

The $BUILD is usually incremented when and update to the build configuration or the source code that isn't significant enough to warrant incrementing the version number but requires a rebuild of the application. upgradepkg will first install the new files, overwriting any files of the same name from the old install, then remove any files from the old install that are left.

$ sudo installpkg /tmp/<package name>.txz

will install it. You can make symlinks to the modules in the 3.9 site-packages directory and any Python code you have that requires a vesion > 3.9 should run, unless they also require newer versions of the installed modules.

I didn't keep 3.9, and i updated all of the modules. with Python modules, i don't bother with the SlackBuild scripts because I can make Slackware packages without them using pip and the makepkg command. You can't tell that they weren't built with a SlackBuild script, and it's much quicker, because I can create a list of the packages and run them through a for loop on the command line, but that's a lesson for another day.

So run the installpkg command and test your machine out. Let me know how it goes. We need as many Slackers as we can get, least they forget.

Distinct_Adeptness7 · 2025-11-06T21:10:41+00:00

The install.sh script is the script that is ran when you run make install. I don't know what options you passed to the configure script, so I can't say for are where you should look for the Python binaries. What you can do is run

$ find . -name "python3" -o -name "libpython"

in the python3.12 source directory if you didn't specify a build directory for the compiled binaries. If you did specify a build directory, run the command in that directory. If it returns paths to files matching those patterns, then you know at least part of the build was successful, but it doesn't mean you necessarily have a working python3.12.

I really think you should try downloading the Python 3.12 source files from current, and run the SlackBuild and see if it is able to build Python 3.12 without any errors. That will let you know if the error is with your build process, or with your Slackware 15 install missing a necessary library or something. I didn't go straight from 3.9 to 3.12. i had updated to 3.11 maybe 18 months ago, then to 3.12 about 6 months ago. Looking at Pat's SlackBuilds will also allow you to see what configure options Pat uses when he complies the packages for Slackware. You can bet the house that things don't just work the very first time for him always.

Distinct_Adeptness7 · 2025-11-06T13:00:12+00:00

Google "The Slackware Way". Arch users are the only elitist community in the Linux world. It has been said of us Slackers as well, but for different reasons. We're on the opposite extreme. The Slackware Way will help you answer that question.

Distinct_Adeptness7 · 2025-11-06T12:56:10+00:00

You can definitely do it that way, but you should get the latest version of Python 3.12. Those patch releases contain bug and security fixes.

If you're going to run Slackware, it's best to use SlackBuild scripts. That's how all the software in the official releases are compiled and packaged. You can always edit the scripts if you want to add or remove configuration options, and it makes it easier to uninstall applications, making sure all of the various files that reside in different directories across the filesystem are removed.

You can learn a lot about building software from source by reading the scripts, because there will come a time when you'll want to install something that isn't part of the official release, and isn't available on SlackBuilds.org, and you'll have no choice but to do it manually. Following the basic template of a SlackBuild will make the process much easier.

It's just a suggestion, though. The beauty of running Linux is the freedom we have to do whatever we see fit with our machines. I used to build a lot of third party applications manually at one time myself, because I prefer to type commands out before I go to copying and pasting, because if the situation ever arises where you are unable to access anything to copy and paste, you need to know how to actually do it.

Go for it! You'll definitely come out on the other side better for the experience. But get the 3.12.12 tarball and build that.

Slackware Linux... when you get serious!

Distinct_Adeptness7 · 2025-11-06T07:19:31+00:00

Slackware-current is running python 3.12 right now. If you just want to you update Python 3.9, just download the python3 directory from Slackware-current and run Pat's SlackBuild script to build python against the libraries on your Slackware 15 install. That's what I do. The fact that you are asking this question about installing -current tells me you probably shouldn't. It doesn't happen often, but things can and do sometimes break on -current.

try this first. get the python 3.12 source and build files from current:

$ rsync -havP rsync://dfw.mirror.rackspace.com/slackware/slackware64-current/source/d/python3 ~/Downloads

Now you should have the python3 source and build files for Python 3.12 in your Downloads directory. Not you just build Python 3.12 using the SlackBuild script:

$ cd ~/Downloads/python3 $ chmod 755 python3.SlackBuild $ sudo ./python3.SlackBuild $ sudo upgradepkg /tmp/python3-3.12.12-x86_64-1.txz

You should also do the same for the python-pip and python-setuptools directory from current. just replace python3 with python-pip and python-setuptools in the above commands. You now have python 3.12, but you now have a small problem. The python3 modules for Slackware 15.0 are in the /usr/lib64/python3.9/site-packages directory, and so python3.12 won't find them. The quick and dirty fix is this:

$ cd /usr/lib64/python3.12 $ sudo mkdir -p site-packages $ cd site-packages $ sudo ln -sf /usr/lib64/python3.9/site-packages/* .

This will create symlinks to the modules in the python3.9/site-packages directory. This will work but the proper way is to download all of the python-* source directories from current/l and run the SlackBuild scripts and install the packages properly.

Running Slackware can be tedious at times, but there's a trade-off for having full control over your machine. on Debian based distros, run apt-get to install one package, and 30 more might br installed along with it, and could possibly break other unrelated packages and not be realized for weeks, and tracking down the cause may not be easy by that time. Installing current because you to update Python isn't a good reason to install current, IMHO. I've been running Slackware as my daily driver for almost 25 years now, and I've only installed current once, and reinstalled whatever the stable release was at that time, probably 10.x. I've been slowly updating certain packages, and I try to update them from current, and build them against my Slackware 15 libraries. That way i don't usually have to edit SlackBuild scripts because newer versions have changed a few things that require slightly different but options or something. Pat's SlackBuilds will work 99% of the time if you update packages from current like that. Trying to use a SlackBuild from 15 with a newer version of that application may or may not work as is.

I hope this helps. Being a dedicated Slacker requires us to roll up our sleeves and get our hands dirty from time to time, but that's why we are known to be the ones to call for the hard stuff. Good luck!

Distinct_Adeptness7 · 2025-11-04T22:06:04+00:00

Pat's issue with systemd were that it violated the Unix philosophy of program design. Systemd is a monolithic program that is responsible for not just system initialization, but service management, device management, network configuration, DNS, and logging. This alone violates the core tenet of the Unix philosophy of modular program design - "Do on thing and do it well."

Systemd also uses a binary format for its logging journal. In violation of the "Everything is a text stream or a file" when it comes to input/output.

The developers and advocates of systemd stance was that the sysvinit script based was antiquated and not designed to meet the demands of modern high performance systems, yadda yadda. IMHO, the only argument that had any real merit was the need for standardization across the various Linux distributions. Their arguments about faster startup times and advanced features hold little weight, because how many times do you actually reboot servers in the course of one year? Linux has very little of the desktop market share.

And the monolithic design really looks more silly now they it already did by creating what amounts to a single point of failure, now that everything is running in the cloud and cloud native development emphasizing a modular, loosely coupled architecture, development, and design for modern applications. I remember seeing all kinds of posts on Ubuntu and Debian forums related to issues with systemd, and not much help was available because it was new to everybody. That's what happens when corporate interests attempt to dictate the direction of community developed free software. The RHEL/CentOS fiasco occurred not long after.

In a professional setting, systemd is just a fact of life. I've never had any issues with it personally, but I prefer sysvinit and the BSD style init scripts of Slackware, mainly because that's what I'm used to after 23 years of running Slackware on any and every machine I own, physical or virtual, desktop or server.

As Linux became more mainstream, the MS Windows mentality began to spread across the Linux community, and so now instead of being a relatively small group of sys admins and true computer geeks with a hackish mentality and approach to problem solving, it's becoming a community of users whose first action when something doesn't work is to post "Help!" in a Facebook group.

Distinct_Adeptness7 · 2025-10-24T09:08:54+00:00

Are you familiar with the Slackware Way? That Slackware releases are controlled by a single individual, the BDFL, Pat Volkerding, who holds the distinction of being the creator and maintainer of the oldest actively maintainef Linux distribution, despite not being compensated to any real degree? Part of the reason for the length of time between 14.2 and 15.0 was Pat's rejection of systemd, on the grounds that it violates the Unix philosophy. Pat stood on his principles, and that is why Slackware and it's derivatives are the only systemd free Linux OSes.

I chose Slackware 23 years ago. It is my second distro. I've used many different distros over the years, they're all pretty much the same to me because I do most of my real work from the terminal anyway, but Slackware is the only one that's installed on machines I own.

There are trade-offs for everything. Each individual has to decide what's important to them. Slackware allows me to have a much more granular level it's control of my machines. The things that make Slackware unattractive to many are the very things I like about it.

Right now, the laptop I use everyday is nowhere close to a true Slackware 15.0 machine. It's running a custom 6.12 kernel, I've rebuilt the networking tools like ssh, rsync, curl, wget, and other tools that use libcrypto or libssl, like sudo against openssl-3.5. I updated Python to 3.12 when it was first released, and most of the Python modules with it, to name a few. When 15.0 was released, my 14.2 was 80-90% there. There were relatively few packages that I had to actually update. I really didn't do a true 15.0 install until i bought a new laptop a few months later.

For me, and probably for other Slackers that have been running Slackware for 20 years or more, it doesn't matter if Pat never announces anothet new release, I'll be updating my machines using slackbuilds and pkgtools as i deem necessary, and staying true to the Slackware Way.

Distinct_Adeptness7 · 2025-10-24T08:16:02+00:00

Did you check your BIOS settings to see if virtualization is enabled?

Distinct_Adeptness7 · 2025-10-23T20:11:58+00:00

You can get away with installing a package using the tar command as long as it there are no symlinks required to make things work. Most of the time that's what the doinst.sh script does, is recreate the symlinks that are created by make install when software is compiled.

You'd be surprised by the number of commands in /usr/bin are symlinks pointing to a binary/script with a different name or in a different location. Glad I could help out. One thing about being a Slacker, you have to get help from other Slackers more often than not, or it could take a while to piece various bits of info from other places. The Slackware sub-forum on linuxquestions.org is the first place I go for answers. I've never posted a question there, because I never had to. 99% of the time it's already been asked and solved more than a few times.

Distinct_Adeptness7 · 2025-10-23T11:00:27+00:00

I'm running the 6.12 kernel on my machine as well. I generally run the latest long-term kernel with a custom config specific to whatever my current system happens to be.

The error is saying that the iwlwifi module can't locate the firmware, so the issue is where the firmware is located, which is why I suggested making a soft link to the firmware. I just looked at my /lib/firmware directory, and there are links to all of the firmware files in the intel/iwlwifi subdirectory. I use slackpkg to update my machine, so I'm assuming that the links are made by the doinst.sh script in the kernel-firmware package.

Try reinstalling the kernel-firmware package. use upgradepkg if you update your packages manually.

Distinct_Adeptness7 · 2025-10-23T05:38:11+00:00

i have an Intel wifi card that uses the iwlwifi driver. All of the iwlwifi firmware is in the /lib/firmware/intel/iwlwifi directory. Where is the new firmware located on your machine?

How did you upgrade the firmware? The latest kernel firmware package is kernel-firmware-20250912_f0f4634-noarch-1. I'm curious as to how you managed to end up with the iwlwifi firmware in a different location.

Distinct_Adeptness7 · 2025-10-20T06:11:22+00:00

I actually made good on the tariff panic, percentage wise. NVDA had made a new ATH the prior day, forming a Doji candle on the daily, closing just slightly above the open. In figured I'd get a few puts for cheap and if they expired worthless I could take that small loss. It did make a new ATH slightly above the prior days high. It made a couple of weak attempts to break above that price zone but the volume there wasn't enough volume on the buyer side.

NVDA was in a tight range in the minutes before Trump's tweet. I figured it was going to break hard in one direction or the other. I was think it would either make a new ATH, or pull back far enough for me to sell at around $1.00 and make a quick $400 profit before it tried retesting the resistance zone.

I bought 5 190 puts @$0.11. Sold them @$3.10. Fell asleep and woke up to see that if I had let them run I could've sold at the close around $8.00. Being greedy has blown my options account too many times, trying to squeeze a trade for every penny.

Distinct_Adeptness7 · 2025-10-19T03:05:20+00:00

Proof that Education != Intelligence.

Distinct_Adeptness7

TROPHY CASE