Frequently Asked Questions

Are you affiliated with and/or endorsed by Slackware?

Do you have a help forum, mailing list, or an IRC channel?

What are all of those .asc files in the repository?

Where is the project's GPG key?

How do I use a SlackBuild script?

How do I submit SlackBuild scripts to the project?

How do I learn to write a SlackBuild script?

Do you have a sample or template SlackBuild script that I can use as a guide?

I've found a problem with one of the scripts - now what?

The download link for the source tarball is not working - now what?

Do I have to run the script as root?

I'm trying to test a script as a normal user, but I get errors indicating that I do not have permission to write in /tmp/SBo - what's wrong?"

Do you keep a list of non-standard user (uid) and group (gid) numbers that we should use in our scripts?

There's a newer version of some app in the repository - who do I tell?

For what release of Slackware are these scripts designed? Will they work on newer versions?

Will these scripts work on older versions of Slackware?

Why don't you provide scripts that work with the Slack/390 or ARM ports of Slackware?

I have problems compiling with my unofficial and unsupported multilib setup.

Do you provide precompiled packages from your SlackBuild scripts?

So what if I want to use your SlackBuild scripts to provide a public repository of precompiled packages?

Why don't you provide a way to resolve dependency information automatically in your scripts?

I'm trying to build ffmpeg (or maybe something else), and the script keeps erroring out due to a missing /usr/man directory (or maybe missing tetex binaries that are installed). What gives?

I'm trying to build a certain package on my custom installation and it failed. Can it be considered a bug?

What's the best way to link to builds on your site from other pages, e.g. upstream project homepages recommending installation methods for our users?

How can I donate to SlackBuilds.org?

I have problems building some scripts from the repository. Are there any solutions?

There are a lot of different JDKs in the repository. Which one should I use in my script?

• No. We are not affiliated with or officially endorsed by either Patrick Volkerding or Slackware Linux, Inc. This project is maintained by volunteers who wish to contribute something useful to the Slackware user community. Furthermore, for clarity's sake, the concept of a SlackBuild script came from Slackware itself, not from us.
• Perhaps this should be noted, however.

• We do not have (nor do we intend to create) a user help forum. However, we do have a Mailing List with archives and an IRC channel on the Libera network at https://libera.chat/ - #slackbuilds - feel free to join and/or stop by!

• Those files are GPG signatures. They can be used to verify that the SlackBuild script tarball is exactly the one that we placed on the site. Assuming you have both the script tarball and the .asc file in the same directory, this process is as simple as:
  gpg --verify app.tar.gz.asc

• Our GPG key is located at https://slackbuilds.org/GPG-KEY

• See our Usage HOWTO page.

• See our Submission Guidelines page.

• See the SlackBuild Writing HOWTO on SlackWiki.com. Be sure to follow our additional guidelines given in the Submission Guidelines page as well, because the SlackWiki article is a "generic" howto.

• Yes, we have several templates and other support files available for download.

• See our Bug Reporting page.

• There are at least two possible causes. First, some upstream providers seem to think that it's a good idea to move link locations around when they make new releases, so the result is that download links to older releases break. If/when this happens, look around on their site and you should usually be able to find the new link. Also, check the README file as it may have some clue as to the source code's new location.
• Another potential cause is that sourceforge seems to have a broken mirror - this has been the case for several months now (time of this writing is 20070606). An easy workaround is to add a timeout to your wget command for downloading the source - see wget(1) for more information; a timeout of 10 seconds should be sufficient.
• It's recommended to use wget instead of browser since browser may have different settings for downloading compressed archive.

• Well, yes and no. The package must be built as root in order for the ownership and permissions to be set correctly (any usage of the chown command inside the script will fail otherwise), but you can certainly test a script by running it as a normal user. You might consider temporarily commenting any chown lines in the script if you're trying to test it as a normal user.
• Don't bother whining about "security issues" or such from building as root. If you don't trust us to check the scripts for malicious activity, then please move along.

• If you have previously run any of our scripts as root (which is required to build a package correctly), the /tmp/SBo ($TMP) directory was created by root during that run, and a normal user account does not have write permissions to that directory. Either give the user write permissions or rm -rf the directory as root before running the script as a normal user.

• We keep a list of recommended UID/GIDs for use with SlackBuilds.org scripts. These do not conflict with default system accounts for Slackware nor with the initial (and subsequent) UIDs recommended by adduser. You can find this list at the url https://slackbuilds.org/uid_gid.txt

• Email the individual who submitted the script and ask them to submit an updated version - you can obtain their contact information in the application's .info file. If you do not get a response and/or if the script is not updated within a reasonable amount of time, post a message to the SlackBuilds.org Users Mailing List. Please do not depend on the IRC channel for this, because many of our submitters do not stay online there, and even if they do, there is no guarantee that they will see your message.

• All of our scripts should work with the most recently released version of Slackware; if this is not the case, you should file a Bug Report. Except as noted in the next FAQ entry, the scripts should also work on older versions of Slackware. Slackware -current is not supported, but as a general rule, the scripts should work on it as well.

• Maybe. Modifying them to do so is usually simple - see our page discussing compatibility with older versions of Slackware. Keep in mind that some things will depend on other things that were not present in older versions of Slackware, so in some cases, it just might be easier to upgrade Slackware :-)

• Due to incompatibilities with S/390 and ARM derivatives of Slackware, those architectures are not supported, nor will we respond to bug reports on those platforms.
• That being said, many of our scripts will work (or are even tested on) those architectures, so they might work just fine.

• If you are using multilib packages from somewhere and also have some 32bit packages installed, then you might run into problems with the build process trying to link 32bit libraries instead of 64bit libraries. If this occurs, it can probably be solved by placing the following line:
    LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
  after the lines for CFLAGS and CXXFLAGS passed to the configure script. In other words, make it look something like this:
    CFLAGS="$SLKCFLAGS" \
    CXXFLAGS="$SLKCFLAGS" \
    LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
    ./configure \
  Beyond that, you are on your own. This is an unsupported setup.

• No. We are not now, nor will we ever be, a source of precompiled packages.

• If you do make such a repository available to the public, we request that you change the "SBo" tag in your packages to something else.
  We do not want to be associated with 3rd-party package repositories. All we will vouch for are the SlackBuild scripts, which we have tested and approved (which is why we always make the GPG ".asc" file available that allows you to check that you are actually using our unmodified SlackBuild script).
  There is no way we can or will guarantee that a 3rd-party package containing the "SBo" tag was created using an unmodified SlackBuilds.org script.

• The short explanation goes something like this: there are too many potential pitfalls associated with automatic dependency resolution in addition to obvious "political" issues surrounding it. Rather than create a potentially buggy implementation or risk the perception of "preferential treatment" toward some third-party package management utility, we chose to omit the inclusion of dependency information (with the exception of noting it in the .info and/or README files). If you want to know what non-Slackware dependencies are required by a package, see the .info file and/or README file associated with its SlackBuild script.

• You probably don't have the tetex binaries in PATH. See the relevant section of our HOWTO page.

• All scripts are tested against a full installation of Slackware (all default install groups) with latest patch. Running a custom installation may cause some builds to fail.

• Use "https://slackbuilds.org/apps/yourappname/" where "yourappname" is the name of your project used on our site. Be sure to include the trailing slash.

• If you'd like to donate to the SlackBuilds.org project, use our PayPal link.

• Read the READMEs. Some maintainer put notes about optional dependencies, available build options, warning about potential conflict with Slackware packages, steps to be taken before building the package and after installing the package, and many other things that relates to the script.
• Some scripts (e.g. webkit2gtk, qt5, chromium) require a lot of memory and system resources. If you have only a small amount of RAM, consider adding additional swap space.
  You can use the following commands to create 10 GB of swap space using a swap file:
    fallocate -l 10G /temp-swap
    chmod 0600 /temp-swap
    mkswap /temp-swap
    swapon /temp-swap
  When you are done building, you can delete the swapfile:
    swapoff /temp-swap
    rm -rf /temp-swap

• We have scripts for all LTS versions of Java from Azul - zulu-openjdk8, zulu-openjdk11, and zulu-openjdk17. Azul provide builds for both 32 and 64 bit (and they even have ARM builds). These are binaries, but freely downloadable and redistributable and make the best default for your script.
• We also have scripts for two LTS versions from Oracle - jdk (JDK8) and jdk11. The Oracle binaries requires registration and logging in to download.
• You'll need to pick the correct version which is supported by the project you are building and running, but either the Azul or Oracle builds should be interchangeable. You can choose to use the Oracle builds if you want, ignoring the REQUIRES.
• If the software your script will package must absolutely run with a particular vendor's JVM, note it in the README.
• There are more vendors shipping OpenJDK builds, but we do not yet have scripts for all of them on SlackBuilds.org. Adoptium (formerly AdoptOpenJDK) has multiple companies backing it, including Red Hat, and is part of the Eclipse Foundation, but they currently only offer x86_64 builds. We also have a source-only build for OpenJDK7 and OpenJDK8, if you want to build yourself completely from source.