diff --git a/Documentation/BUILD b/Documentation/BUILD index 6b153e8df..baf96c329 100644 --- a/Documentation/BUILD +++ b/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 ' (where 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 ' 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/' 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 -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 '. 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//ROCK/bootdisk/, where 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 diff --git a/Documentation/BUILD-CLUSTER b/Documentation/BUILD-CLUSTER index f1dcba9c4..614387c9a 100644 --- a/Documentation/BUILD-CLUSTER +++ b/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 - -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 diff --git a/Documentation/BUILD-CROSS b/Documentation/BUILD-CROSS index 04bc2ee39..247e98278 100644 --- a/Documentation/BUILD-CROSS +++ b/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//root using NFS and boot the cross-built kernel on the target architecture with nfs-root. diff --git a/Documentation/BUILD-DIETLIBC-TARGET b/Documentation/BUILD-DIETLIBC-TARGET index c43d40bae..8b037cf34 100644 --- a/Documentation/BUILD-DIETLIBC-TARGET +++ b/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" diff --git a/Documentation/Developers/HACKING-HOWTO b/Documentation/Developers/HACKING-HOWTO index 70b7b61fa..9061a0708 100644 --- a/Documentation/Developers/HACKING-HOWTO +++ b/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 . @@ -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 the name 'default' is used. It parses the metaconfig files described in chapter 3 and creates the files -in config//. If an config-name is specified it also has do -been passed to the other scripts, too. +in config//. 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 diff --git a/Documentation/Developers/PATCHES b/Documentation/Developers/PATCHES index 11fe67cf1..8b29f1006 100644 --- a/Documentation/Developers/PATCHES +++ b/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 diff --git a/Documentation/Developers/PKG-BUILD-VARS b/Documentation/Developers/PKG-BUILD-VARS index 0bb440359..ec144a231 100644 --- a/Documentation/Developers/PKG-BUILD-VARS +++ b/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) diff --git a/Documentation/Developers/PKG-DESC-FORMAT b/Documentation/Developers/PKG-DESC-FORMAT index 8840298eb..75997f122 100644 --- a/Documentation/Developers/PKG-DESC-FORMAT +++ b/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. diff --git a/Documentation/Developers/PKG-FLAGS b/Documentation/Developers/PKG-FLAGS index cea242d97..6b3fce5b8 100644 --- a/Documentation/Developers/PKG-FLAGS +++ b/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() diff --git a/Documentation/Developers/POLICY b/Documentation/Developers/POLICY index 3be27edf2..59fe808e6 100644 --- a/Documentation/Developers/POLICY +++ b/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! diff --git a/Documentation/Developers/STABLE-TREE b/Documentation/Developers/STABLE-TREE index 3d505dceb..e0ec8a1e4 100644 --- a/Documentation/Developers/STABLE-TREE +++ b/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. diff --git a/Documentation/Developers/TODO b/Documentation/Developers/TODO index 1c985afc6..581860756 100644 --- a/Documentation/Developers/TODO +++ b/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. diff --git a/Documentation/README b/Documentation/README index ed3c20f62..a731ee2eb 100644 --- a/Documentation/README +++ b/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 . 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