Last update: May 13, 2008
This page describes how to build the binary GSB distribution from the actual GSB source code. It is recommended that you read through (end even print) this entire document before starting the build process.
For other aspects of the GNOME SlackBuild Build system, please return to Main page.
The first step to building your GNOME Desktop with GSB is to check out our source code from our svn repository. Please make sure to do so in a directory on a disk partition that has quite a bit of free space. The GSB Build System itself doesn’t not take up much disk space, however, the source tarballs are downloaded directory into the build tree. A full source build tree can take up to 1GB of disk space. We currently maintain several SVN branches to produce our GSB releases.
You can check out the GSB Build System using the following command:
Current Branch
This tree contains the latest and most up to date GSB sources. As such, at any time it may be broken (ie, will not build fully) or may cause your system to explode in a shower of wires and capacitors if you run it. This tree is usually only for the latest Slackware/Slamd64 current and may not work on other releases.
$ svn co http://svn.gnomeslackbuild.org/gsb/trunk gsb
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/trunk
GNOME 2.22 Stable Tree
This is our GNOME 2.22 stable tree for Slackware 12.1 and Slamd64 current (which will soon become Slamd64 12.1) ONLY. This tree is kept up to date with the GNOME 2.22 sources and will be maintained (at least for the short->medium timeframe) with the minor 2.22.x releases GNOME provide.
$ svn co http://svn.gnomeslackbuild.org/gsb/branches/gsb-2.22 gsb22-stable
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/branches/gsb-2.22
GNOME 2.20 Stable Tree
This is our GNOME 2.20 stable tree for Slackware and Slamd64 12.0 ONLY. This tree is kept up to date with the GNOME 2.20 sources and will be maintained (at least for the short->medium timeframe) with the minor 2.20.x releases GNOME provide.
$ svn co http://svn.gnomeslackbuild.org/gsb/branches/gsb-2.20 gsb20-stable
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/branches/gsb-2.20
This may take a long time depending on the speed of your internet connection. The svn GSB tree does not only contain our own scripts and patches for building the GNOME Desktop, but also contains external links to other software available via svn, such as the x264 Codec library and NetworkManager. These external links via svn will ease the building of such packages. However, the majority of the tree will consist of SlackBuild build scripts (.SlackBuild), Slackware package description files (slack-desc), and Slackware package requirements (slack-required) files.
If you have difficulties building a package, before reporting any errors, please make sure your Build Tree is up-to-date. Changes to the trunk can happen daily, and the fix may already be applied to the build tree. To update your tree to the latest version, change into the gsb directory and run:
$ svn update
Apart of the GSB Build System is a download script written in perl, which is kept up to date with all the versions and download locations of all the source tarballs used by the GSB Build System. This is for the convenience of any user who wishes to build GSB from scratch. The download script is designed to download the source tarballs for the entire GSB Build Tree, which can be up to 1GB. Users may find they either do not want this, and may only want to use the GSB Build Tree for building a few select packages. In this case it may be easier to download the tarballs by hand into each package’s directory.
The perl download script is called gsb_update.pl, and it is found in the gsb/bin directory. There are two settings you may wish to change before running the download script. To do this, you will need to edit the GSB.pm file found in the directory gsb/lib/perl/GSB.
################################################################################ # Config Options # 'mirror' => 'ftp://ftp.gnome.org/pub/gnome' my $wget_options = "--continue --cache=on --passive-ftp --progress=bar:force --timeout=30 --tries=3";
gsb_update.pl script uses wget to download all the soure tarballs. If you would like to change the default settings for the GSB download script, please consult the wget manual.When you are ready to run the download script, change into the gsb/lib directory and run:
$ ../bin/gsb_update.pl --dl --edit --build=gsb
--dl
This argument will tell gsb_update.pl to download all the source tarballs.
--edit
This argument will tell gsb_update.pl to edit the SlackBuild to reflect the version number which is downloaded from the GSB.pm source files, as well as reset the build number if the version has changed.
--build=gsb
gsb_update.pl to tag all the packages with “gsb”. When the package is built, the string “gsb” will be appended to the package build number, i.e., 1gsb.tgz, rather than 1.tgz. This will help differentiate it from regular Slackware provided packages.
Downloading the sources may take a while depending on the speed of your internet connection. Don’t be surprised if it takes a few hours. :)
Disk space requirements are the first priority. It may seem surprising at first, but a complete GSB Build may require up to 8GB of disk space! There is a lot of software that will be compiled during the build process and it is important to ensure that enough free disk space is available before starting the build scripts. The disk space usage is broken down as such:
GNOME SlackBuild Source Tree: ~261MB
This includes all the GNOME SlackBuild scripts, as well as all external svn sources.
GNOME SlackBuild Source Tarballs: ~1GB
This is approximate for a full source download. If you only wish to build a few single packages then if may be easier for you to download each source tarball individually.
Temporary building space: ~6GB
Some larger applications like Mozilla Firefox, Mono, and Boost C++ require enormous amounts of space to build. Despite the fact that the resulting binaries are often only about 30MB, while building they may need up to 3-6GB for object files and libraries.
Installed Software: ~2GB.
As the GSB Build system steadily progresses building packages, it will need to install them on the build system for the sake of satisfying dependencies. In other words, the system on which GSB is built will also have it installed. A full installation of GSB will required approximately 2GB
GNOME SlackBuild Packages: ~563MB
GNOME SlackBuild will produce standard tgz format Slackware packages, placing all the built packages into the default directory /tmp/gsb-packages. A full GSB Build will require space for about 360 individual packages.
A full development system is also required to build GSB. You will need to ensure that the following standard Slackware packages are installed on your system:
autoconf, automake, bin86, binutils, doxygen, flex, gcc, gcc-g++, gettext-tools, guile, indent, kernel-headers, libtools, m4, make, perl, pkg-config, python, subversion
All of these packages are installed on a “full” Slackware install, but some users who installed a custom selection may not have these packages installed. They are available on any Slackware CD, or available from any Slackware mirror. For those users who are interested, we provide a set of tagfiles to be used during a Slackware installation which will install the same set of Slackware packages we use on our own build system. They are available in the trunk/lib/gsb/tagfiles/build-box directory.
One caveat for builders is that some standard Slackware packages will need to be upgraded, most notably glib2 and libwnck. Others will need to be upgraded for added functionality, but these packages are optional. Please take a look at all the packages that may require replacing in our Replaced Packages file.
# The following is a list of packages that can replace official Slackware packages. # # Packages listed under 'Required' are Slackware packages that must be replaced # by corresponding GNOME SlackBuild versions in order to use GNOME 2.22.1 on Slackware 12. # Reasons for their replacement are given within brackets. # # Packages listed under 'Optional' are packages which replace official Slackware # packages, but their replacement are only necessary for added functionality, or # certain GNOME applications. Their replacement is recommended, but not required # if you do not plan to use certain applications, or are dead set against replacing # any Slackware provided packages. # # List last updated: May 4th (stevek) # ********************************************** Slackware 12.1 is required to run GNOME 2.22.1 ********************************************** -- Required Package Replacements for GNOME 2.22.1 on Slackware 12.1 -- glib2: ( > 2.15 required by libgnome 2.22, Gvfs 0.2.3, and Nautilus 2.22) libwnck: ( > 2.22 required by Metacity 2.22, and GNOME 2.22 at large) -- Optional Replacements -- mozilla-firefox: (Provides shared libraries. Required by: Epiphany, Yelp, GNOME Python, DevHelp) compiz-fusion: (Slackware comes with compiz 0.7.4, compiz-fusion is cooler though and offers GNOME support) libgsf: (Slackware's libgsf lacks GNOME support; required for GNOME Office applications like Gnumeric)
You will also need a live internet connection in order to build some packages.
It is also recommended that you have the latest patches for Slackware applied.
When building GSB, there are several environment variables which can be used to tweak and customise the build process. GSB supports two methods of setting these environment variables, described below.
The first option is to use the bash builtin “export” to manually set the option and export it to all sub-processes. This can be done with a command like:
$ export VAR="VAL"
This can be repeated for as many environment options as you want to set. You must remember to set these options every time you begin a build process as they will not be saved accross multiple builds.
The second option is to create a gsb.options file in the src/ directory. The gsb.options file is read at the begining of every build process, and the options specified in this file will be saved accross multiple builds. Using the gsb.options file is especially useful for repeat builds or for developers who want to set specific options when testing.
The gsb.options file should contain exactly the same “export” commands which would be used manually on the command line (see above). The advantage of putting them into the gsb.options file is that the options will always be read, no matter whether you remember to manually export them on the command line.
Here are the common environment variables which can be set to effect, tweak or customise the build process:
ARCH
Setting the ARCH allows you to over-ride the default base architecture type for GSB. You can use this environment option to build GSB for, say, x86_64 or the powerpc architecture type. The architecture type set when building GSB determines the absolute minimum processor type required to run the produced binaries. In other words, if you set ARCH=i686 the resulting code will NOT work on an i586 or earlier CPU. These ARCH types are currently recognised by the GSB SlackBuild scripts: i386, i486, i586, i686, x86_64, powerpc.
The default is “i586”.
TUNE
This option is very similar to the ARCH environment option except that the resulting binaries are scheduler-tuned to the given processor type. This means that the binaries will be tuned to run with better performance on the CPU type specified with TUNE, but will still work without problems on CPU types going back to the value specified for ARCH. TUNE can be set to any valid CPU type within the architecture type specified with ARCH. For example, if ARCH=i586, TUNE could be set to i686. For an ARCH type of x86_64, TUNE must be set to one of the 64 bit processor types, currently: k8, opteron, athlon64, athlon-fx.
The default is “i586”, except for an ARCH type of x86_64 where it is “k8”.
You may find more information on ARCH and TUNE settings in the gcc man pages.
DISTRO
Setting DISTRO to anything other than “slackware” allows GSB to be built on different (Slackware based) distributions. For example, this can be set to “slamd64” when building GSB on the 64 bit Slackware based distro Slamd64.
The default is “slackware”, and should not be over-ridden unless you are specifically building for another distribution.
TMP
During the package builds, temporary data will need to be stored on disk. This option specifies the directory where that temporary data can be written. Make sure the default (or any directory you specify) has enough free space for the build process, plus the completed packages and logs.
The default is /tmp.
PKGDEST
Once a package has been built it will be stored in the directory specified with this option. The default for this option is affected by the value of the TMP environment option detailed above (referred to as $TMP below).
The default is $TMP/gsb-packages.
LOGSDIR
As the GSB build process proceeds, a log of the output from each package build is logged for later debugging. This environment option specifies the directory where these log files will be stored. This option is not used by individual package SlackBuilds but is used by the top-level SlackBuilds which control the build processes. The default for this option is affected by the value of the TMP environment option detailed above (referred to as $TMP below).
The default is $TMP/gsb-buildlogs.
The following options are less common but allow highly specific customisation of the build process. You should not set these options unless you know exactly what needs to be set for each. GSB comes with fairly optimised complier settings, but if you really want to squeeze every last cycle out of your CPU, you can adjust compiler and make settings. Be wary though! Sometimes hyper-optimising can break software that depends on careful or ISO-standard math routines, for example, liboil.
GSB_CONFIGURE_FLAGS
Any options specified in this environment variable are ADDED to the package specific options passed to the ./configure command in the SlackBuilds. If this option is set globally (ie, set with export or in gsb.options) it sets the additional options passed to ./configure for EVERY SlackBuild in GSB. Therefore, make sure that any setting given in this environment option is valid for EVERY ./configure used in GSB.
By default, when ARCH=x86_64, ./configure is automatically passed—libdir=/usr/lib64.
GSB_TUNE_FLAGS
This environment option allows you to set the specific tuning options gcc should use when compiling/linking the binaries in packages. There are many, many gcc options which can be set to optimise/tune the binaries – see the gcc man page for full details. Setting this option over-rides the default tuning options specified in the SlackBuild files – these options are NOT added to the default ones. Make sure you add any of the default options from the SlackBuilds back to this environment option if you choose to use it. Tuning is specific to each ARCH, with the defaults being:
-O3 -march=$ARCH -mtune=$TUNE-O3 -march=$ARCH -mtune=$TUNE -pipe -fomit-frame-pointer -ffast-math-O3 -march=k8 -mtune=k8 -pipe -fomit-frame-pointer -ffast-math -fPIC-O3 -march=$TUNE -mtune=$TUNE -pipe -fomit-frame-pointer -ffast-math -fPIC-O2 -march=$ARCH
GNOME SlackBuild is organized by logical sections, like “libraries” or “platform”, under which are placed related packages. Each section is governed by a section build script, which will build all the package within its section in the proper build order. These section build scripts have their own unique arguments as follows:
--help
Show this help screen.
--list
List the packages which will be built in this section.
--force
A package will not be built if a package of the same name is already installed, or any of the pre-requisite packages are not installed. This option over-rides the checks and attempts a build (which will probably fail) anyway.
--no-skip
During the build process, packages that are up to date (ie, the package version and build numbers match the
corresponding SlackBuild) will not be rebuilt. This option forces packages to be rebuilt regardless of the version and build numbers. This does not affect the pre-build checks for installed packages (see—force).
--no-metafiles
Do not create the .txt and .md5 files for each package which would usually be produced during a build. Normally, metapackages are created for use with slapt-get and the binary install method. If you do not need to create these metapackages (normally, only for binary distribution managers), then you may specify this argument.
--no-prune
Normally, when a package is built and copied to the destination directory, any previous package(s) of the same name are deleted – it is assumed the new package is to replace any which were built previously. This option prevents previous packages being deleted from the destination directory, possibly leaving more than one package of the same name (but with different version or build numbers) laying around.
--no-patchesdir
When rebuilding packages which already exist in the main package directory, the default is to put the new packages in the patches directory. Using this option completely disables the use of a patches directory.
--no-cleanup
By default, any source, temporary build and package directories will be deleted once the package is built. This option prevents those files from being removed.
--no-install
Build packages but don’t install them. This should only be used for testing individual SlackBuilds as it can cause some package builds to fail, specifically those which may rely on another package being auto installed first.
NOTE: Options are passed down to the individual package SlackBuilds where appropriate.
Each individual SlackBuild script has its own arguments. By default, it will not run if the package it builds has previously been installed. It will also check for basic build requirements, and display package names of any missing required packages. Each SlackBuild will configure, build, and create a Slackware .tgz package complete with a slack-required and slac-desc file.
--force
The package will not be built if a package of the same name is already installed, or any of the packages required to build are missing. This option over-rides these checks and attempts a build anyway. It cannot be used with the -update switch.
--update
This switch will make the build script test each package version as defined in the SlackBuild script against the currently installed package. If there is a difference, the script will remove, rebuild, and reinstall the package. It cannot be used with the -force switch.
--no-cleanup
By default any temporary source, build and package directories will be deleted once the package is built. This option prevents those files from being removed.
--no-install
Build the packages but don’t install them. This should only be used for testing individual SlackBuilds. It may cause the section build to fail when required packages are not installed and the dependency checks fail.
--help
Show this help screen.
Building every package provided by GNOME SlackBuild will take a long time. We have separated packages into sections in order to aid building in a proper order, as well as to make maintaining dependencies easier. If you do not wish to run the entire build in one go, you may build section by section (ie, by hand), following the build order below. We have, however, provided there is one overarching script, gsb.SlackBuild which will run each of the section SlackBuild’s in the proper order.
This master list is defined within the gsb.SlackBuild file itself, and each section SlackBuild has it’s own defined build order. The binary distribution provided compiles every package listed, but if you prefer to roll your own GSB packages, then feel free to edit the order to suit your own needs or wants. But be warned, if everything breaks, it’s not our fault! :)
Also, be aware that before running the build script, you must be root in order to build GSB.
$ ./gsb.SlackBuild
Don’t panic. :) We’ve worked hard to ensure that all the packages within the GSB Build Tree will build on Slackware. If you have difficulties building a package, before reporting any errors, please make sure your Build Tree is up-to-date. Changes to the trunk can happen daily, (and even hourly!), and the fix may already be applied to the build tree. Before reporting errors, please make sure to have updated your tree to the latest version. Change into the gsb directory and run:
$ svn update
If you discover yourself still having difficulty building a certain package or packages, let us know and we’ll try our best to resolve any issues. There are several mailing lists used by the GNOME SlackBuild project. These are hosted by Google Groups, and in order to read or post to the mailing lists and groups, you must first subscribe. Give IRC a try first, but if no-one is around, then please do send an email detailing the problem you are having, with all the appropriate details, like OS and compiler versions, the exact error, and steps to reproduce it. You may also want to check the archives or FAQ to see if the problem is already known.
Try one of the following (in this order):
Firstly, check the archive to see if anyone else has had a similar problem which has already been solved. You will not get any points for requesting help with a problem that has already been addressed.
The mailing list is the easiest and preferred method of contact for support type issues – it allows us to keep an archive of questions and answers. Note: You must be subscribed to the mailing list in order to post messages.
You may also use this wiki. For reporting any new issues, or feature requests, please see our Issues page. You may create new issues or features using the drop-down menu on the right.
Last update: May 12, 2008
This page contains some useful information for people who want to start work developing the GNOME SlackBuild source. We are always looking for volunteer help to any aspect of GNOME SlackBuild, whether it be coders, documentation writers, bug finders, graphic designers, or even friendly advise and encouragement.
Come along to chat in the #gsb IRC channel on freenode.net or send an email to the development list.
If you are looking for other aspects of the GNOME SlackBuild Build system, please return to Main page.
There are several mailing lists used by the GNOME SlackBuild project. These are hosted by Google Groups, and in order to read or post to the mailing lists and groups, you must first subscribe. For details about subscription and a full list of our mailing lists, please see our Lists web page.
If you are a developer who would like to work on the GNOME SlackBuild project, you are encouraged to subscribe to two important mailing lists:
We have a variety of ChangeLogs available, including an SVN ChangeLog which gives an up to the minute description of the changes that are being made to the SVN developement tree, as well as ChangeLogs available for the binary builds of GNOME SlackBuilds. For a complete list of our ChangeLogs, please see ChangeLog web page.
The only method supported of getting the GNOME SlackBuild source tree is to check out our source code from our svn repository. Please make sure to do so in a directory on a disk partition that has quite a bit of free space. For details about the disk space requirement, please see the Build page, and look at the Disk Space requirements.
Our development takes place in trunk, and if you would like to help develop GNOME SlackBuild, you will need to check this out. ‘trunk’ will always hold our latest build tree and sources, and this is where the majority of the work goes on.
You can check out the GSB Build System using the following command:
Current Branch
This tree contains the latest and most up to date GSB sources. As such, at any time it may be broken (ie, will not build fully) or may cause your system to explode in a shower of wires and capacitors if you run it. This tree is usually only for the latest Slackware/Slamd64 current and may not work on other releases.
$ svn co http://svn.gnomeslackbuild.org/gsb/trunk gsb
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/trunk
GNOME 2.22 Stable Tree
This is our GNOME 2.22 stable tree for Slackware 12.1 and Slamd64 current (which will soon become Slamd64 12.1) ONLY. This tree is kept up to date with the GNOME 2.22 sources and will be maintained (at least for the short->medium timeframe) with the minor 2.22.x releases GNOME provide.
$ svn co http://svn.gnomeslackbuild.org/gsb/branches/gsb-2.22 gsb22-stable
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/branches/gsb-2.22
GNOME 2.20 Stable Tree
This is our GNOME 2.20 stable tree for Slackware and Slamd64 12.0 ONLY. This tree is kept up to date with the GNOME 2.20 sources and will be maintained (at least for the short->medium timeframe) with the minor 2.20.x releases GNOME provide.
$ svn co http://svn.gnomeslackbuild.org/gsb/branches/gsb-2.20 gsb20-stable
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/branches/gsb-2.20
This may take a long time depending on the speed of your internet connection. The svn GSB tree does not only contain our own scripts and patches for building the GNOME Desktop, but also contains external links to other software available via svn, such as the x264 Codec library and NetworkManager. These external links via svn will ease the building of such packages. However, the majority of the tree will consist of SlackBuild build scripts (.SlackBuild), Slackware package description files (slack-desc), and Slackware package requirements (slack-required) files.
If you would like more information about using subversion, please visit their website and read the Subversion Book
The best way to help the project is to use GSB. With more users and testers, we are more likely able to catch and fix problems. Making sure to report problems you come across is very appreciated and helps immensely. The only thing greater than reporting a problem is offering a solution! Dive right in. Please take a look at our Issues page for the latest and open list of bugs. Patches and fixes are very welcome.
But there are many other ways of helping out the project:
Packages
Hosting
Translations
Testers
Graphics
What’s the current long term plan for GSB? GNOME is under constant development and improvement, and one of our goals is to follow it as it progresses. Alongside the stable version of GNOME, we will try to maintain a -current branch, which will house the latest and greatest package versions before releasing them into stable. Below is a brief outline of what we have planned.
Last update: May 12, 2008
GNOME SlackBuild is a unique project in that it is designed to be a twofold project. Its aim is not only to provide users with binary packages for an easy installation of GNOME, but also a full GNOME Build System, with the goal of allowing individuals to customise and build their own GNOME packages for their Slackware system.
This wiki is dedicated to the management and documentation about our build system. We provide our full build system, that is to say, it is the full and complete GSB source code we use to generate our binary distribution. It is a collection of SlackBuild scripts that build a GNOME release on Slackware Linux. The build system also comes with a download script to grab all the latest source tarballs for every package that GSB can build.
The structure of the build system is quite simple. The source tree is governed by a gsb.SlackBuild, which will run build scripts for each of the sections of the GSB Project. GSB has been broken into logical sections, such as “libraries”, “platform”, “desktop”, “applications”, and so on. In turn, each section has its own master build script which controls what packages and in what order things are compiled and installed for that section. Within each section, each individual package has its own SlackBuild script which will configure, compile, and build its own Slackware package.
The GSB Build System is aimed at all levels of users. Those who are new to Slackware or to Linux as a whole will find the GSB Build System easy to use, and rather simple to modify. Intermediate and advanced users will find it heavily customisable, and will be pleased to find that the majority of the grunt work in designing and building packages is done for them; they will be free to tweak or patch any packages to their own taste.
We have a page which gives detailed instructions on how to build the binary GSB distribution from the actual GSB source code. It is recommended that you read through (end even print) this entire document before starting the build process. It covers topics about how to check out our source from SVN, download the source tarballs, customise your build settings, and run the build. This version of GSB is designed to build packages using:
If you are trying to build GSB on systems other than the above you will encounter problems during the build.
We cannot offer any form of support to users trying to build GSB on earlier versions of Slackware or Slamd64. However, if you do manage to get GSB built on other versions, please let us know what modifications you had to make to the build system in order to do so – if those changes can be integrated into our build system, you may find those versions supported out of the box in our future releases.
The developers use a strictly controled base of packages to build the binary packages for the project – we only install the minimum packages required to perform a build. We work from a set of ‘tagfiles’ which specify exactly which packages get installed into our build environment. We have included our tagfiles set in the lib/gsb/tagfiles/ directory in our SVN tree for reference.
When it comes to building your own packages, it is doubtful your build will succeed if you do not have every package marked with an “ADD” in our tagfiles installed on your system. Those packages marked “ADD” form the basis of our build requirements – any missing packages from your system will likely cause the build to fail. If you have a full installation of Slackware or Slamd64 you should not have any problem doing a build, but the resulting packages may have more dependancies than indicated in our slack-required files (because many of the sources will find extra libraries when being configured and automatically link against them).
Unless you really know what you are doing with packages, understand what tagfiles and dependancies are all about, and really feel the need to “roll your own”, it would be a far far better choice for you to download the pre-built binaries and install those.
For the brave, please find more information about the Build System, please see our Build page.
This page contains some useful information for people who want to start work developing the GNOME SlackBuild source. We are always looking for volunteer help to any aspect of GNOME SlackBuild, whether it be coders, documentation writers, bug finders, graphic designers, or even friendly advise and encouragement. On this page you will find information about our mailing lists, our ChangeLogs. information about our repositories (both source and binary), our RoadMap, and our TODO list.
Come along to chat in the #gsb IRC channel on freenode.net or send an email to the development list.
For more information for interested developers, please see our Development page.
We have implemented a new Wiki for tracking any bugs or issues; this forum also allows users to request any new features they would like to see implemented in GNOME SlackBuild. Before reporting a new bug, please do a quick search to see if your bug has already been reported. Also, if you are reporting any bugs about the GSB Build system, please make sure that your are using the latest SVN source tree. We work hard to fix bugs quickly, and it may be that the fix has already been applied to the source tree.
Do one of the following (in this order):
Firstly, check the archive to see if anyone else has had a similar problem which has already been solved. You will not get any points for requesting help with a problem that has already been addressed.
The mailing list is the easiest and preferred method of contact for support type issues – it allows us to keep an archive of questions and answers. Note: You must be subscribed to the mailing list in order to post messages.
You may also use this wiki. For reporting any new issues, or feature requests, please see our Issues page. You may create new issues or features using the drop-down menu on the right.