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 uid and 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?

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

• 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 freenode network at irc.freenode.net - #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 http://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.

• 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 http://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 README files). If you want to know what non-Slackware dependencies are required by a package, see the 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.