Frequently Asked Questions
Questions and Answers
Are you affiliated with and/or endorsed by Slackware?
- 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.
Do you have a help forum or an IRC channel?
- We do not have (nor do we intend to create) a user
help forum. However, we do have a
and an IRC channel on the freenode network at irc.freenode.net
- #slackbuilds - feel free to join and/or stop by!
What are all of those .asc files in the repository?
- 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
Where is the project's GPG key?
How do I use a SlackBuild script?
How do I submit SlackBuild scripts for inclusion in 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?
- Yes, we have several templates and
other support files available for download.
I've found a problem with one of the scripts - now what?
The download link for one of the source tarballs is not
working - now what?
- 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.
Do I have to run the script as root?
- 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.
- 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?"
- 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.
Do you keep a list of non-standard uid and gid numbers that
we should use in our scripts?
- 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
There's a newer version of some app in the repository - who do I tell?
- 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
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.
For what version of Slackware are these scripts designed?
Will they work on newer versions?
- 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.
Will these scripts work on older versions of Slackware?
- 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 :-)
Why don't you provide scripts that work with the
Slack/390 or ARM ports of 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
- That being said, many of our scripts will work
(or are even tested on) those architectures, so
they might work just fine.
I have problems compiling with my unofficial and unsupported multilib setup.
- 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:
after the lines for CFLAGS and CXXFLAGS passed to the
configure script. In other words, make it look something
Beyond that, you are on your own. This is an unsupported setup.
Do you provide precompiled packages from your SlackBuild scripts?
- No. We are not now, nor will we ever be, a source
of precompiled packages.
So what if I want to use your SlackBuild scripts to provide
a public repository 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
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.
Why don't you provide a way to resolve dependency
information automatically in your scripts?
- 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.
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).
- You probably don't have the tetex binaries in
PATH. See the relevant section of our
[ Exec: 0.0263 sec | Load: 0.01 0.04 0.05