GNU Development Resources
This page describes many of the development resources available for
GNU developers on GNU Project machines. For full details of the
privileges and responsibilities of GNU maintainers, please see the Information for GNU Maintainers document, and
also follow the GNU Coding Standards.
Also interesting to review may be the tips for GNU maintainers and
overview of what it means to
be a GNU package.
With the abundance of inexpensive computers that can run GNU/Linux, as well as the greater
availability of Internet access, many GNU volunteers today have all the
computer facilities they need. However, there are still advantages to
having central computers where GNU volunteers can work together without
having to make their own machines accessible to others.
For that reason, the Free Software Foundation strongly encourages GNU
software projects to use the machines at
gnu.org as a home
base. Using these machines also benefits the GNU Project indirectly, by
increasing public awareness of GNU, and spreading the idea of working
together for the benefit of everyone.
Savannah and version control
If you are developing an official GNU package, we strongly recommend
using a public source control repository on Savannah, the GNU hosting server.
To do this, first create yourself an
account and then register your GNU package.
After it is created, you will be able to choose a version control
system, create web pages for your package, manage permissions for
contributors to the pages, and many other features.
We operate mailing lists for GNU software packages as needed,
including both hand-managed lists and automatically managed lists.
When a GNU package is registered on Savannah, a web interface allows
developers to create and manage mailing lists dedicated to their
Each GNU package name ought to have at least a bug-reporting
list with the canonical name
plus any aliases that may be useful. Using Savannah, you can create
lists for your package with names like this. Some packages share the
list email@example.com but we now encourage packages to set up their
own individual lists.
Packages can have other lists for announcements, asking for help,
posting source code, for discussion among users, or whatever the package
maintainer finds to be useful.
Mailing list archives for automatically-managed lists are available
at lists.gnu.org (mbox archives available through rsync
and ftp), as well as through the list
manager. Archives for hand-maintained lists are generally kept in
/com/archive on the GNU machines.
When a mailing list becomes large enough to justify it, we can set up
gnu.* newsgroup with a two-way link to the mailing
The master GNU web server is http://www.gnu.org/. We very strongly
recommend that GNU packages use
http://www.gnu.org/software/package as their primary
Using Savannah, developers can create and maintain their own pages at
that url via a CVS “web repository”, separate from the
package's main source repository (which can use any supported version
control system). More
information on maintaining GNU web pages.
The primary ftp site for GNU software on
which is mirrored worldwide. We very
strongly recommend that all GNU packages upload their releases here (in
addition to any other location you find convenient).
We use a different server for test releases, so that people won't
install them thinking they are ready for prime time. This server is
for GNU Maintainers document has complete details on the ftp upload
process, which is the same for both servers.
We provide shell login access to GNU machines to people who need them
for work on GNU software. Having a login account is both a privilege and
a responsibility, and they should be used only for your work on GNU.
Instructions for obtaining an account
machines are written separately.
On the general login machine, the gsrc
package developers maintain a hierarchy of the current GNU package
releases (/gd/gnu/gnusys/live), compiled from the original
sources. To use it, source /gd/gnu/gnusys/live/setup.
You can also use a
GNU account for email.
Hydra: Continuous builds and portability testing
Continuous build tools (often referred to as continuous integration
tools) allow programming errors to be spotted soon after they are
introduced in a software project, which is particularly useful for
cooperatively developed software.
Hydra is a free continuous
build tool based on the Nix package
manager. Administrators of the Hydra
instance at the Delft University of Technology have generously
offered slots for the GNU
Project. Projects on Hydra get re-built at each commit
or change in their dependencies, whichever comes first (dependencies
include the standard build environment being used, which
itself contains recent released versions of GCC, GNU make,
Currently it can build software on GNU/Linux (i686 and
x86_64) as well as FreeBSD, Darwin, Solaris, and Cygwin, and
can cross-build for GNU/Hurd, GNU/Linux on other architectures, and
MinGW. It can provide code coverage reports produced using LCOV. In
addition to source tarballs and Nix packages, it can build packages for
RPM-based distributions. Packages
can be built against the latest versions of their dependencies; for
instance, GnuTLS is built using GNU libtasn1 and GNU libgcrypt
builds corresponding to their latest revision.
In addition to the web
interface, Hydra can send notifications by email when the build
status of a project changes—e.g., from
FAILED. When a build fails, its log and build tree are
accessible from the web interface; the latter allows generated files
be inspected, which provides debugging hints.
Any GNU software package can request a slot on Hydra. Each package
must provide its own “build recipe” written in the Nix
language (a Nix expression, in Nix parlance). Nix
expressions for GNU projects are available via Git. For simple
projects using standard GNU build tools such as Automake and Autoconf,
the recipe is usually fairly simple. For example, see the recipe
for GNU Patch. You are welcome to ask for guidance on firstname.lastname@example.org.
After constructing your build recipe, email email@example.com
and ask to be included in Hydra. Also make sure to become a member of
project at Savannah. This will allow you to customize your
project's build job directly.
For technical information about Hydra, please consult the
manual of Hydra (PDF).
For more details, please refer to the Nix
manual and the
platform-testers: Manual portability testing
Another useful option for pre-release testing is the platform-testers
mailing list. Time permitting, the people on this list build
pre-releases on a wide variety of platforms upon request. (Volunteers
to handle testing requests are needed! Just subscribe to the list and
In contrast to the Hydra tool described above, the platform-testers
list works essentially by hand, so each method has its advantages and
disadvantages. Also, the platform-testers crew has access to a wider
variety of platforms and compilers than the Hydra setup.
So, if you have a pre-release, you can write to the mailing list,
providing (1) the url to the tarball, (2) the planned date of
the release, and (3) the email address to which build reports
should be sent. The builds and reports are made by hand by the
volunteers on the list.