Browse Source

Stefan Fielder:


			
			
				rocklinux
			
			
		
Stefan Fiedler 21 years ago
parent
commit
10e1495d47
13 changed files with 98 additions and 89 deletions
  1. +27
    -14
      Documentation/BUILD
  2. +13
    -13
      Documentation/BUILD-CLUSTER
  3. +1
    -1
      Documentation/BUILD-CROSS
  4. +4
    -4
      Documentation/BUILD-DIETLIBC-TARGET
  5. +28
    -32
      Documentation/Developers/HACKING-HOWTO
  6. +3
    -3
      Documentation/Developers/PATCHES
  7. +2
    -2
      Documentation/Developers/PKG-BUILD-VARS
  8. +2
    -2
      Documentation/Developers/PKG-DESC-FORMAT
  9. +1
    -1
      Documentation/Developers/PKG-FLAGS
  10. +4
    -4
      Documentation/Developers/POLICY
  11. +2
    -2
      Documentation/Developers/STABLE-TREE
  12. +2
    -2
      Documentation/Developers/TODO
  13. +9
    -9
      Documentation/README

+ 27
- 14
Documentation/BUILD

@ -7,8 +7,8 @@
===============
For building ROCK Linux you need a good internet connection for downloading the
sources, a lot of disk space, a fast computer and some time. Depending on the
configuration you are going to choose and your hardware, a build of ROCK Linux
sources, a lot of disk space, a fast computer and some time. Depending on your
hardware and the configuration you are going to choose, a build of ROCK Linux
can take some days to complete. You also need root permissions to build ROCK
Linux.
@ -17,7 +17,7 @@ It is also possible to build ROCK Linux on other distributions, but don't expect
it to work without some hacking ...
If you are building on older ROCK Linux versions (1.4/1.6) you should at least
make sure to upgrade/install the packages "Curl" "mktemp" and "coreutils".
make sure to upgrade/install the packages "curl", "mktemp" and "coreutils".
2. Extracting the sources
@ -25,7 +25,8 @@ make sure to upgrade/install the packages "Curl" "mktemp" and "coreutils".
Download the ROCK Linux sources (a tar.bz2 file of a few MB) from
www.rocklinux.org and extract it somewhere as root. The resulting directory
is the ROCK Linux 'base' directory.
is the ROCK Linux 'base' directory. Change to this directory for the following
steps.
3. Configure the build
@ -36,14 +37,14 @@ your configuration (or simply leave the default values untouched). You need to
start the Config tool - even if you don't want to change anything.
It's also possible to have multiple configurations. Use the command
'./scripts/Config -cfg config-name' (where config-name can be any text not
'./scripts/Config -cfg <config-name>' (where <config-name> can be any text not
containing whitespaces or any special characters). If you have choosen a name
for your configuration, you need to pass the '-cfg config-name' option as
for your configuration, you need to pass the '-cfg <config-name>' option as
first parameter to all the other scripts too - so they know which
configuration to read.
The default configuration name (when no -cfg option is passed) is 'default'.
The configuration is stored in the 'config/config-name' directory.
The configuration is stored in the 'config/<config-name>' directory.
4. Downloading the package sources
@ -51,7 +52,7 @@ The configuration is stored in the 'config/config-name' directory.
Now you need to download the sources for the packages which are build in the
configuration you have choosen. Simply type:
'./scripts/Download -cfg config-name -required'
'./scripts/Download -cfg <config-name> -required'
If you want to download the sources for all packages (regardless if they are
required for your configuration), type './scripts/Download -all'.
@ -59,16 +60,28 @@ required for your configuration), type './scripts/Download -all'.
5. Building the distribution
============================
Type './scripts/Build-Target -cfg config-name'. As mentioned already, it may
Type './scripts/Build-Target -cfg <config-name>'. As mentioned already, it may
take multiple days for the build to complete.
The resulting distribution is stored in the build/ directory.
6. Creating CD Images
=====================
6. Creating bootable floppy images
==================================
Bootable floppy images are created along with each 'bootdisk' target, and are
stored in build/<config-id>/ROCK/bootdisk/, where <config-id> corresponds to
the configuration you choose.
The images are named floppy1.img, etc. and can be copied to floppy disks e.g.
with 'dd'. Simply type: 'dd if=floppy1.img of=/dev/floppy/0 bs=512' for every
image.
7. Creating CD/DVD images
=========================
To create a CD-Image to install from you can use './scripts/Create-ISO'.
To create CD images to install from you can use './scripts/Create-ISO'.
Create-ISO takes at least two arguments: a name used as prefix for the
filename of the ISO images and the name of the configuration you
just built (usually 'default' or whatever you choose after -cfg).
@ -78,7 +91,7 @@ Another optional parameter is -mkdebug which will create a VMWare-Config
to be used with your newly created iso.
The iso will, however, not be bootable, unless you configured and built
a 'bootdisk'-Target. This configuraton has to be the first configuration to
a 'bootdisk' target. This configuraton has to be the first configuration to
be passed to './scripts/Create-ISO'.
So, a complete call might look like this:
@ -97,7 +110,7 @@ If you have a DVD-Writer, you could also pass '-size 4300' and write that iso
on a DVD. That would make approx. 5 to 6 builds on one DVD.
7. Cleaning up the source tree
8. Cleaning up the source tree
==============================
Simply type './scripts/Cleanup' to remove the src* directories. DO NOT REMOVE

+ 13
- 13
Documentation/BUILD-CLUSTER

@ -21,7 +21,7 @@ ROCK Linux has it's own job scheduler to distribute jobs over the cluster
nodes. But you can also use any job scheduler you have already installed on
your cluster to do the job.
When building ROCK Linux in parallel (cluster) mode, the build scripts simple
When building ROCK Linux in parallel (cluster) mode, the build scripts simply
decide based on the package dependencies which packages might be build in
parallel and builds them parallel (instead of serial, which is the default
behavior).
@ -35,7 +35,7 @@ config option is not available when making a parallel (cluster) build.
===============
In a famous paper Amdahl observed that one must consider an entire application
when consider the level of available parallelism. If only one percent of a
when considering the level of available parallelism. If only one percent of a
problem fails to parallelize, then no matter how much parallelism is available
for the rest, the problem can never be solved more than one hundred times
faster than in the sequential case.
@ -49,7 +49,7 @@ after the base packages have been built).
The tool './scripts/Create-ParaSim' can be used to "simulate" a parallel build.
Just configure your build and run './scripts/Create-ParaSim'. The output is a
graph showing how many paralell jobs are available for building in which phase
graph showing how many parallel jobs are available for building in which phase
of the Build. It looks like this:
----+----------------------------------------------------------------------+
@ -76,12 +76,12 @@ of the Build. It looks like this:
You can see that the build doesn't parallelize very well in the early phase
but soon reaches a state where over 100 jobs can be built at the same time.
That the number of available jobs going down in the right side of the graph
That the number of available jobs is going down in the right side of the graph
is normal. When E.g. 400 of 424 jobs are already built, there are only 24
jobs left and so it's not possible anymore to have 100 parallel jobs.
Note that the X-axis is the number of jobs built already - and not the time.
so that graph is telling you somethign about the level of parallelism which
so that graph is telling you something about the level of parallelism which
is possible in your selected configuration in general - but it does not provide
exact numbers how much faster the build would be e.g. on a 16 node cluster.
@ -89,7 +89,7 @@ You can pass the option '-jobs N' to ./scripts/Create-ParaSim to get a
simulation of the build on a cluster with N nodes. The script assumes that the
cluster nodes are as fast as the system which has done the reference build. If
your cluster nodes are e.g. about 20% faster, your build will be about 20%
sooner compleated as printed in the stat. You can even compare builds - e.g.
sooner completed as printed in the stat. You can even compare builds - e.g.
"-jobs 1,2,8" would compare a "normal" single-node build with a build on a
2-node cluster and an 8-node cluster:
@ -117,7 +117,7 @@ sooner compleated as printed in the stat. You can even compare builds - e.g.
If you have 'gnuplot' installed and $DISPLAY set, you can also pass the option
'-x11' to ./scripts/Create-ParaSim so it will use the program 'gnuplot' to
graph the results. A screenshot of the '-x11' mode of ./scripts/Create-ParaSim
can be found at http://www.rocklinux.org/pics/screenshot_parasim.jpg.
can be found at http://www.rocklinux.net/pics/screenshot_parasim.jpg.
3. Setting up the master
@ -170,14 +170,14 @@ Now your cluster is ready for building ROCK Linux.
5. Building with the built-in job scheduler
===========================================
Run './scripts/Build-Target' in /home/rock-master the master. Instead of
Run './scripts/Build-Target' in /home/rock-master on the master. Instead of
building the packages the master will create a job queue and add those
packages to the queue which can be built next.
Run './scripts/Build-Job -daemon' in /scratch/rock-node on the nodes. Again,
you might want to use 'prsh' to do this on all nodes. If you want to build
multiple packages parallel on one cluster node (e.g. because they have two
CPUs) you need to run './scripts/Build-Job -daemon' as often as many jobs
CPUs) you need to run './scripts/Build-Job -daemon' as often as how many jobs
you want to run on the node at the same time.
"Build-Target" on the master will show you what's going on. You can view
@ -215,19 +215,19 @@ config option 'Command for adding jobs' to the value
addjob 'cd /scratch/rock-node ; {}'
The text {} will automatically replaced with the Build-Job invocation for
The text {} will automatically be replaced with the Build-Job invocation for
building the package and always has the form of:
./scripts/Build-Job -cfg <config-name> <stagelevel>-<package-name>
So if you want to make some inteligent job scheduling (e.g. build large
So if you want to make some intelligent job scheduling (e.g. build large
packages on a faster node) you can also pass {} to another script and
have the command in $*, the config name in $3 and the stagelevel and
package name in $4.
If not all jobs can be executed, the job scheduler should prefer those jobs
which have been submitted first. This is importand to make sure that it always
is possible that multiple packages can be build in parallel.
which have been submitted first. This is important to make sure it is always
possible that multiple packages can be build in parallel.
Note that './scripts/Build-Job -daemon' does not work if the 'Command for
adding jobs' config option is set. The './scripts/Create-ParaStatus' script

+ 1
- 1
Documentation/BUILD-CROSS

@ -51,7 +51,7 @@ and "make vmlinux" (or something like "make bzImage").
3. Installing the results
=========================
This is the most complitated step and may be diffircult for some architectures.
This is the most complicated step and may be difficult for some architectures.
You need to export the system in build/<config-id>/root using NFS and boot the
cross-built kernel on the target architecture with nfs-root.

+ 4
- 4
Documentation/BUILD-DIETLIBC-TARGET

@ -14,14 +14,14 @@ Index
Hi, this here is a small howto build the dietlibc target. I hope that it
will be some time no more needed because the target will be so
strateforward. Currently it is more a draft for a howto but who cares it
straightforward. Currently it is more a draft for a howto but who cares it
is more then nothing, right ? ;-)
Some pretty internal stuff is in Documentation/Developers/TODO . There
are also current problems and bugs put together so even if you are not a
developer you probably would like to read it.
The target is currently experimental, so be carefull because it can kill
The target is currently experimental, so be careful because it can kill
your pet, make your mother angry, make you sleepless or simply not work
and/or compile.
@ -52,7 +52,7 @@ with prepended diet wrapper. For this run this commands:
# mv /usr/bin/cc /usr/bin/cc.bak
# vi /usr/bin/cc
And insert the following code it the file:
And insert the following code in the file:
#!/bin/sh
exec diet gcc "$@"
@ -67,7 +67,7 @@ dietlibc target.
4) Build
~~~~~~~~
Do the same what is described in Documentation/Build apropriatly
Do the same what is described in Documentation/Build appropriately
selecting dietlibc target in scripts/Config .
Please disable the "Create cache files after packages have been built"

+ 28
- 32
Documentation/Developers/HACKING-HOWTO

@ -168,13 +168,13 @@ packages together. All packages with a repository do belong to the same
maintainer or maintainer-team.
Within the repository-directory, every package has it's own subdirectory.
E.g. the 'gcc3' package can be found in "package/base/gcc3/".
E.g. the 'gcc' package can be found in "package/base/gcc/".
1.3.1. package/base/
--------------------
The "base" repository contains the most important core-packages. Stuff like
the compiler, the kernel and the standard unix command-packages (fileutils, ..).
the compiler, the kernel and the standard unix command-packages (coreutils, ..).
The "base" packages are maintained by Clifford Wolf <clifford@rocklinux.org>.
@ -242,14 +242,17 @@ the config/ tree. Every configuration has it's own subdirectory there.
2. Build- and other scripts
===========================
Most scripts print a help text, containing a description of syntax and
options, when started with the '-help' option.
2.1. ./scripts/Config
=====================
./scripts/Config is the main configuration script. If no config-name is
specified via the option -cfg config-name the name default is used.
./scripts/Config is the main configuration script. If no configuration name
is specified via the option -cfg <config-name> the name 'default' is used.
It parses the metaconfig files described in chapter 3 and creates the files
in config/<config-name>/. If an config-name is specified it also has do
been passed to the other scripts, too.
in config/<config-name>/. If a config-name is specified it also has to
be passed to the other scripts, too.
2.2. ./scripts/Download
=======================
@ -327,10 +330,10 @@ build (cluster) mode.
==========================
2.4.1. ./scripts/Cleanup
-----------------------
------------------------
The Cleanup script can be used to remove the src* and build* directories which
are created by the build scripts. Never remove this directories manually!!!
are created by the build scripts. Never remove these directories manually!!!
On default ./scripts/Cleanup only removes the src* directories. the build*
directories are only removed when the -full option is passed.
@ -360,14 +363,14 @@ packages file.
Creates a list of packages which could be built next. The first parameter is
the maximum number of packages to print (0=no limit) and the 2nd parameter is
the root directory where the script can find the /var/adm/... information it
need. E.g.:
needs. E.g.:
# ./scripts/Create-PkgQueue 3 build/1.7.0-DEV-intel-generic/root
2 X --2------9 010.050 base strace 4.4 / development/tool 159
2 X --2------9 010.052 base ltrace 0.3.10 / development/tool 85
2 X --2-4----9 010.055 base perl5 5.6.1 / development/interpreter 125
The script is primary used by ./scripts/Build-Target.
The script is primarily used by ./scripts/Build-Target.
2.4.5. ./scripts/Create-SrcTar
------------------------------
@ -437,13 +440,6 @@ Update (re-build) all packages on the local system for which newer versions
are available. Create-UpdList is used to generate the list of packages which
do need an update.
2.4.13. ./scripts/Puzzle
------------------------
Some files in the ROCK Linux source tree are automatically created. This
script recreates all of them and should be called whenever one of the source
files have been changed.
2.4.14. ./scripts/Help
----------------------
@ -501,7 +497,7 @@ package dependencies.
---------------------------
Update the source tree with rsync from www.rocklinux.org.
Warning: This will remove the changes you made to the source tree.
Warning: This will remove the changes you have made to the source tree.
3. Configuration System
@ -527,7 +523,7 @@ including which other files.
Whenever the menu is displayed (i.e. after starting ./scripts/Config and
whenever a change has been made), scripts/config.in is executed and is using
he following special commands to write the 'config' file and add items to the
the following special commands to write the 'config' file and add items to the
menu.
3.2.1. comment 'Description' ["Help"]
@ -676,7 +672,7 @@ ROCKCFG_EXPERT If set to '0', config items between expert_begin and
The ROCKCFGSET_* variables can be used to preset an option (e.g. in a target).
If e.g. ROCKCFGSET_STRIP is set to 1, ROCKCFG_STRIP will have the value 1 and
the user would not be able to change this setting.
the user will not be able to change this setting.
3.3.3. CFGTEMP_*
----------------
@ -764,7 +760,7 @@ Cat. Package categories (always lower case, contain at least one /)
Flags Package flags (always upper case)
Counter Simply ignore that filed
Counter Simply ignore that field
Because of the 'counter' field, categories and flags are always pre- and
postfixed with a ' '. So you can e.g. easy remove all not dietlibc-ready
@ -853,7 +849,7 @@ with e.g.:
If the checksum is simply '0', this means that no checksum has been created so
far. The script ./scripts/Create-CkSumPatch can be used for creating a patch
which fills in thos checksums.
which fills in those checksums.
For files which should not have a checksum for one or another reason (e.g.
because the content on the original site is changing often), a checksum-string
@ -862,7 +858,7 @@ consisting of only 'X' characters can be used. E.g.:
[D] XXXXXXXXXX RFCs3001-latest.tar.gz ftp://ftp.rfc-editor.org/in-notes/tar/
The 2nd field is the filename. Files with the postfix *.gz or *.tgz are
automaticallt converted to *.bz2 or *.tbz2 files by the ./scripts/Download
automatically converted to *.bz2 or *.tbz2 files by the ./scripts/Download
script.
The 3rd parameter is the download URL without the filename part. If the local
@ -926,7 +922,7 @@ package selection, force some special configuration to be used, supply
additional patches to each package, modify any build aspect of a package and
more.
The most important file of a target is the 'preconfig.in' file where there
The most important file of a target is the 'preconfig.in' file where the
target needs to register itself via:
CFGTEMP_TARGETLIST="$CFGTEMP_TARGETLIST target_name Long_Visible_Name"
@ -940,25 +936,25 @@ called:
pkgloop
or to also generate some databse files for the install-cd the generic
or to also generate some database files for the install-cd the generic
build.sh can be reused:
. target/generic/build.sh
A target specific .conf file or patch for a package may be easily be added
A target specific .conf file or patch for a package may easily be added
by placing it under the name pkg_$pkg.conf or pkg_$pkg.patch in the target's
directory. Where $pkg is the name of the respective package.
Some package mmight have target specifig hooks, like the linux* package use
a kernel.conf.sh in the target's directory to perform additional config
Some packages might have target specific hooks, like the linux* package which
uses a kernel.conf.sh in the target's directory to perform additional config
work on the kernel's .config file.
6. Architectures
================
Aside from the fact that each arcitecture needs at least to register itself
Aside from the fact that each architecture needs at least to register itself
to the ROCK Linux build system, it might provide patches and kernel
configuartion to work properly.
configuration to work properly.
The registering works via the preconfig.in file - just like for the targets:
@ -969,10 +965,10 @@ introduce new options (just like the config.in in several other places).
The file gcc-options controls additional options passed to GCC.
The files kernel{$treever,}.conf{m4,sh,} and kernel-disable{treever,}.lsl
The files kernel{$treever,}.conf{m4,sh,} and kernel-disable{treever,}.lst
are used to control the options used for the linux kernel build.
As already mentioned in the explaination of packages, architecture specific
As already mentioned in the explanation of packages, architecture specific
patches are added to the respective package with a patch.$arch suffix.
A archtest.out or archtest.sh file should be present to define some constants

+ 3
- 3
Documentation/Developers/PATCHES

@ -12,14 +12,14 @@ Please use the ROCK Linux Submaster server to commit patches:
https://www.rocklinux.net/submaster/
If you send patches to the mailing list, make sure that someone else is
putting it into submaster for you. Otherwise you risk that you patch might
putting it into submaster for you. Otherwise you risk that your patches might
be ignored or get lost.
More information about submaster can be found at
http://www.rocklinux.org/submaster.html
The package also contains a command-line tool to easily create patches and
This page also contains a command-line tool to easily create patches and
send them to the submaster server.
If you really need to send patches per mail, please put the string [PATCH]
@ -29,7 +29,7 @@ start of the subject in the mail index.
0. DON'T SEND UNTESTED PATCHES WITHOUT POINTING OUT CLEARLY THAT THEY ARE
UNTESTED AND DON'T EXPECT UNTESTED PATCHES TO GET APPLIED. In cases of
package updates, etc. it's already enought to test if the package still
package updates, etc. it's already enough to test if the package still
builds fine in a more or less generic configuration.
1. Patches should be in the the unified- or context-format. We prefer

+ 2
- 2
Documentation/Developers/PKG-BUILD-VARS

@ -3,7 +3,7 @@ Variables used in the package build scripts
===========================================
config ........ Name of the active configuration ($base/config/$config/..)
extraver ...... version text after the fist whitespace, or $rockver
extraver ...... version text after the first whitespace, or $rockver
rockver ....... ROCK Linux Version (including rel. date for snapshots)
pkg ........... base name part of the package we are building
@ -39,7 +39,7 @@ prefix ........ install prefix (usually '/usr' or '/opt/...')
prefix_auto ... '1' = you may auto-detect a better value for $prefix in *.conf
build_logs .... Big build log file ...... (Build-Target only)
build_pkgs .... Packagfiles go here ..... (Build-Target only)
build_pkgs .... Packagefiles go here .... (Build-Target only)
build_root .... Chroot dir name ......... (Build-Target only)
build_rock .... ROCK build system data .. (Build-Target only)

+ 2
- 2
Documentation/Developers/PKG-DESC-FORMAT

@ -7,7 +7,7 @@ Please use the tags in the same order as they are listed in this file. Add
a blank line wherever a '--' is found here and use the X-* flags after all
the other tags. "./scripts/Create-DescPatch" can help you here.
All tags marked with (*) are required. And should be present in every .desc
All tags marked with (*) are required and should be present in every .desc
file.
- Clifford and Rene
@ -67,7 +67,7 @@ file.
Format: [R] + intel
Format: [R] - sparc powerpc
Usually a packge is built on all architectures. If you are using [R]
Usually a package is built on all architectures. If you are using [R]
with '+' the package will only be built for the given architectures.
If you use it with '-' it will be built for all except the given
architectures.

+ 1
- 1
Documentation/Developers/PKG-FLAGS

@ -13,7 +13,7 @@ CXX A C++ compiler (the package is using ROCKCFG_DEFAULT_CXX)
F77 A Fortran compiler (the package is using ROCKCFG_DEFAULT_F77)
KCC A C compiler for building the kernel (ROCKCFG_DEFAULT_KCC)
KERNEL A OS kernel package
KERNEL An OS kernel package
MTA Package is an MTAs and is using install_setmailer()
PRINTER Printing System and is using install_setprinter()

+ 4
- 4
Documentation/Developers/POLICY

@ -41,16 +41,16 @@ which can't be done by the build scripts would break rule 1.
4. Patches
A patch should always be submitted to the package maintainer if it could
A patch should always be submitted to the package author if it could
be useful to the rest of the world - a bug should always be reported to the
package maintainer, if possible.
package author, if possible.
It's useless to fix a bug only for ROCK Linux and not letting the rest
of the community profit from the patch ...
5. System start up
A service/daemon should be only started on default if it's absolute
necessary. A fresh installed system should not open any network port or
A service/daemon should be only started on default if it's absolutely
necessary. A freshly installed system should not open any network port or
configure a network interface. If the administrator needs it, he/she will
enable it!

+ 2
- 2
Documentation/Developers/STABLE-TREE

@ -32,8 +32,8 @@ broken instead of fixing it.
2. Updating packages to newer versions
--------------------------------------
Package updates should be performed unless the newer vrsion of a package
introduces new problems or brakes compatibility with the old package and so
Package updates should be performed unless the newer version of a package
introduces new problems or breaks compatibility with the old package and so
would require rebuilding a large part of the system.

+ 2
- 2
Documentation/Developers/TODO

@ -9,7 +9,7 @@ ROCK Linux Todos and Ideas:
- Fix -fstack-protector for glibc (currently it's simply disabled)
- Append architecture to GEM packages
- Add an FHS-checker to 00-dirtree (using 'postinstall' hook)
- lcap has a broken URL and seams to be disapared from the net.
- lcap has a broken URL and seems to have disappeared from the net.
- refactor the architecture boot code from the bootdisk to the
architecture subdir - so the mulitple targets can utilize the
code
@ -25,7 +25,7 @@ ROCK Linux Todos and Ideas:
- find out why "Plan A" of patch does not work on dietlibc (-x 16
switch for patch in scripts/Create-Pkg)
- add perl to the target. textutils needs it :-/
- reanable man generation in textutils
- reenable man generation in textutils
- the gcc version compiled with dietlibc has problems with the
-pipe option. When you use this option then you get linker errors.
It is a very strange problem because it is not always there.

+ 9
- 9
Documentation/README

@ -8,7 +8,7 @@
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* *
* ROCK Linux is Copyright (C) 1998 - 2003 Clifford Wolf *
* ROCK Linux is Copyright (C) 1998 - 2004 Clifford Wolf *
* *
* Read the file 'COPYING' for licensing details. *
* *
@ -34,22 +34,22 @@ english, you can can select your language in:
Documentation/i18n/
There are some ROCK Linux Mailinglists. You can subscribe to the main ROCK
Linux List by sending an e-mail with the subject "subscribe rock-linux"
to <minimalist@rocklinux.org>. You can unsubscribe by sending an e-mail
with the subject "unsubscribe rock-linux" to the same address. The lists
address is rock-linux@rocklinux.org. A mailing list archive can be found at:
There are several ROCK Linux Mailinglists; you can find more information at:
http://www.rocklinux.org/mailing-list/
http://www.rocklinux.org/mail.html
A mailing list archive can be found at:
http://www.rocklinux.net/lurker/splash/
Please don't send questions or bug-reports directly to one of the
maintaners unless you have a really good reason for.
maintainers unless you have a really good reason to do so.
We also have a channel on the Free Node IRC Network (irc.freenode.net). The
channel name is #rocklinux. There are also IRC Logs and IRC Stats available
online at:
http://www.rocklinux.net/people/esden/irclog/ and
http://www.rocklinux.net/irclog/ and
http://www.rocklinux.net/people/esden/ircstat/
If you want a more human introduction to ROCK Linux, please visit

Loading…
Cancel
Save