Index: /main/waeup.aaua/trunk/CHANGES.txt
===================================================================
--- /main/waeup.aaua/trunk/CHANGES.txt	(revision 11375)
+++ /main/waeup.aaua/trunk/CHANGES.txt	(revision 11376)
@@ -5,5 +5,7 @@
 =====================
 
-* No changes yet.
+* Removed sphinx docs.
+
+* Added generic install instructions.
 
 
Index: /main/waeup.aaua/trunk/INSTALL.txt
===================================================================
--- /main/waeup.aaua/trunk/INSTALL.txt	(revision 11376)
+++ /main/waeup.aaua/trunk/INSTALL.txt	(revision 11376)
@@ -0,0 +1,395 @@
+Installation of Kofa on Linux production system
+###############################################
+
+.. note:: `waeup.kofa` and its custom packages
+          might not work with Python > 2.7
+          currently. Use of Python 2.7 is recommended.
+          The installation is described for Linux-based computers.
+
+Part 1: Deploying Kofa as a single Zope client install
+******************************************************
+
+Prerequisites
+=============
+
+The Kofa packages are based on `Grok`_, which is a Python
+framework for agile webapplication development. Grok itself is based
+on `Zope`_.
+
+.. _Grok: http://grok.zope.org/
+
+.. _Zope: http://www.zope.org/
+
+Both, Grok and Zope, are written in Python (with parts written in
+C). You therefore need `Python`_ installed.
+
+.. _Python: http://www.python.org/
+
+Note, that you also need the Python header files and a compiler to
+compile the parts written in C.
+
+To deploy Kofa most easily, we use `zc.buildout`_
+
+.. _zc.buildout: http://cheeseshop.python.org/pypi/zc.buildout
+
+
+Preparing the system
+====================
+
+To create a working copy of Kofa we recommend use of
+`virtualenv`. You, however, need also some basic libraries, a C
+compiler and some things more.
+
+What you need (Debian/Ubuntu package names in brackets):
+
+* Python 2.7 (python2.7)
+
+* Python 2.7 development files (python2.7-dev)
+
+* A C-Compiler (gcc)
+
+* The C library development files (libc6-dev)
+
+* A subversion client (svn)
+
+* enscript (enscript) [optional]
+
+  This is only needed if you want test coverage reports.
+
+All these packages can be installed on Debian systems like this::
+
+  # apt-get install python2.7 python2.7-dev python2.7-dbg \
+                    gcc libc6-dev svn enscript
+
+Afterwards you should be able to enter::
+
+  $ python2.7
+
+at the commandline and get a Python prompt. Quit the interpreter
+pressing <CTRL-D>.
+
+
+Installing `virtualenv`
+=======================
+
+We recommend use of `virtualenv` to create Python sandboxes where you
+can run your code without touching any other installations.
+
+If you don't already have ``easy_install`` available, you can find the
+script to set it up on the `PEAK EasyInstall page`_.
+
+.. _`PEAK EasyInstall page`: http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install
+
+You need to download `ez_setup.py`_. Then, you run it like this to
+install ``easy_install`` into your system Python::
+
+  $ sudo python2.7 ez_setup.py
+
+.. _`ez_setup.py`: http://peak.telecommunity.com/dist/ez_setup.py
+
+This will make ``easy_install`` available to you.
+
+.. note:: Sometimes you have ``easy_install`` installed but you need a
+          newer version of the underlying setuptools infrastructure to
+          make Grok work. You can upgrade setuptools with::
+
+            $ sudo easy_install -U setuptools
+
+Now you can install `virtualenv` by doing (as root)::
+
+  # easy_install-2.7 virtualenv
+
+This step will fetch all needed sources from the internet and install
+`virtualenv` locally in your Python2.7 installation.
+
+
+Creating a sandbox
+==================
+
+This step is only necessary (and recommended) if you installed
+`virtualenv` before.
+
+As a normal user you now can create a sandbox for your upcoming work
+by::
+
+  $ virtualenv --no-site-packages mysandbox
+
+where ``mysandbox`` is a directory in the filesystem where your
+sandbox will be created. `virtualenv` will also create this directory
+for you.
+
+By passing the ``no-site-packages`` switch we tell `virtualenv` to
+provide us a clean environment without any extra-packages installed
+systemwide.
+
+You now can activate the sandbox by doing::
+
+  $ source mysandbox/bin/activate
+
+You will notice that the input prompt changes.
+
+To deactivate the sandbox at any time, enter::
+
+  (sandbox27)$ deactivate
+
+and the prompt will be the same as before the activation.
+
+For the following steps make sure the sandbox is active.
+
+
+Creating a working place
+========================
+
+In the sandbox we now create our real working
+environment. To do this, we change to the sandbox and checkout the
+sources of Kofa from the subversion server::
+
+  (sandbox27)$ cd mysandbox/
+  (sandbox27)$ svn co https://svn.waeup.org/repos/main/waeup.kofa/trunk kofa-trunk
+
+where ``kofa-trunk`` is only a name we've chosen here to make clear
+where the sources come from. In this case we are installing the Kofa base
+package.
+
+The command should fetch the Kofa base package sources for you and
+put it in the directory ``kofa-trunk/``.
+
+Now enter the new directory::
+
+  (sandbox27)$ cd kofa-trunk
+
+
+Preparing the build
+===================
+
+In the sources directory (``kofa-trunk/``) you have to prepare the
+project to fetch needed components (eggs), compile C-code parts,
+etc. This steip will not touch any external projects::
+
+  (sandbox27)$ python bootstrap.py
+
+This will generate some directories and the ``buildout`` script in
+``bin/`` for us. This step must be executed only once for each
+instance.
+
+You can now deactivate the sandbox::
+
+  (sandbox27)$ deactivate
+
+Now we can do the real build by triggering::
+
+  $ bin/buildout
+
+If this is your first install of some Grok-related project, this step
+will need some time as lots of sources have to be fetched, many
+components must be compiled, etc.
+
+This step must be redone whenever you change something in
+``buildout.cfg`` or ``setup.py``.
+
+Note that if you have more than one sandbox for a Zope-based web
+application, it will probably make sense to share the eggs between the
+different sandboxes.  You can tell ``zc.buildout`` to use a central
+eggs directory by creating ``~/.buildout/default.cfg`` with the
+following contents::
+
+    [buildout]
+    eggs-directory = /home/bruno/buildout-eggs
+
+
+Start the instance
+==================
+
+You should be able now to start the created instance by doing::
+
+   $ bin/zopectl fg
+
+Alternatively you can do:
+
+    $ bin/paster serve parts/etc/deploy.ini
+
+The port numbers where Kofa is running on your server are defined in
+buildout.cfg under [kofa_params].
+
+If you now point a browser to the right port on your server, for example ::
+
+   localhost:8080
+
+you should get a login pop-up, where you can login as superuser with
+``grok`` and ``grok`` as username/password (Kofa base package only!).
+
+You can stop the instance by pressing <CTRL-C>.
+
+If you are connected and logged in,
+you should be able to add the grok-based applications
+(such as ``University``) from the menu.
+
+Add an instance of ``University`` and click on the link next to the
+then visible entry in the list of installed applications.
+
+Running the tests
+=================
+
+The tests are easily run by executing the test runner that's
+installed in the ``bin`` directory::
+
+    $ bin/test
+
+
+Part 2: Deploying Kofa as ZEO install
+*************************************
+
+Each ZEO install consists of at least one ZEO server and normally two
+or more ZEO clients. While the ZEO server is meant to manage the ZODB
+database for clients, the clients connect to the outside world, listen
+for request and do the real dataprocessing.
+
+We prepared a `buildout` configuration that sets up one server
+configuration and two client configs. This configuration is in
+``buildout-zeo.cfg``.
+
+Generating the ZEO setup
+========================
+
+To install Kofa ZEO-based you can run `buildout` with the given
+(or your own) configuration file like this::
+
+  $ ./bin/buildout -c buildout-zeo.cfg
+
+This should generate all scripts necessary to run servers, clients,
+etc.
+
+Starting ZEO servers and clients
+================================
+
+First start the server::
+
+  $ ./bin/zeo_server start
+
+Clients can be started by doing::
+
+  $ ./bin/zeo_client1 start
+  $ ./bin/zeo_client2 start
+
+This will start both clients in daemon mode.
+
+Instead of ``start`` you can, as usually, start an instance in
+foreground (``fg``), etc. You know the drill.
+
+
+Manually starting ZEO clients
+=============================
+
+This is normally not neccessary.
+
+``zeo_clientN`` scripts are basically wrappers around calls to
+``bin/paster``. You can bypass this wrapper and start a client
+'manually' like this::
+
+  $ ./bin/paster serve --pid-file var/zeo1.pid --daemon \
+        pars/etc/zeo1.ini
+
+It is important to give a pid-file as paster otherwise can not start
+different clients (they would all refer to the same pid file
+`paster.pid` and refuse to start after the first client was started).
+
+
+Setup (paramters, ports, etc.)
+==============================
+
+By default the server will listen on port 8100 for requests from
+localhost (not: from the outside world).
+
+You can change ZEO server settings in the ``[zeo_server]`` section
+of ``buildout-zeo.conf``. Run `buildout` afterwards.
+
+The clients will listen on port 8081 and 8082. You can change settings
+in ``etc/zeo1.ini.in`` and ``etc/zeo2.ini.in`` respectively. Run
+buildout after any change.
+
+If you want to change the paster wrapper for any zeo client, you can
+edit ``etc/zeo1.conf`` and/or ``etc/zeo2.conf``. Run buildout
+afterwards.
+
+
+Creating new clients
+====================
+
+You want more clients to be created by buildout? Easy. Three steps are
+neccessary.
+
+1. Create config files in etc/
+------------------------------
+
+Each client needs two configuration files:
+
+  - ``etc/zeoN.conf``
+       configuring the paster wrapper
+
+  - ``etc/zeoN.ini``
+       configuring the runtime config, ports, etc.
+
+Just copy over these files from the already existing zeo1/zeo2 files
+and replace ``zeo1`` or ``zeo2`` with your new name.
+
+2. Update buildout-zeo.cfg
+--------------------------
+
+Here, inside ``buildourt-zeo.cfg`` also three steps are needed.
+
+* 2.1. Create new .ini and .conf entries
+
+  The .conf and .ini files in etc/ are only templates that have to be
+  generated in their really used final location. In buildout-zeo.cfg
+  you can care for this by creating a new ``[zeoN_ini]`` and
+  ``[zeoN_conf]`` option (replacing ``N`` with a number, of course).
+
+  Just copy over existing entries and replace the mentions of ``zeo1``
+  or ``zeo2`` by your ``zeoN``.
+
+* 2.2. Create a new ``zeo_clientN`` entry
+
+  Then you have to create an entry that will generate the
+  ``zeo_clientN`` script. Again, just copy over an existing
+  ``[zeo_client1]`` entry and replace ``1`` withg your client number.
+
+* 2.3. Register the new sections in ``[buildout]`` section
+
+  When done with the above: add the new section in ``[buildout]``::
+
+    [buildout]
+      ...
+      <old entries...>
+      ...
+      zope_conf_zeo_5
+      zeo5_ini
+      zeo_client5
+
+  depending on how you named your new sections.
+
+3. Rerun ``buildout``
+---------------------
+
+When adding or removing client/server instances, make sure to stop all
+running servers/clients before rerunning buildout.
+
+To activate the new setup, rerun buildout::
+
+  $ bin/buildout -c buildout-zeo.cfg
+
+This should generate any new clients and remove older ones or just
+update configuration files.
+
+
+Considerations
+==============
+
+There are some things in the current buildout-zeo.cfg we might do not
+want. It extends the regular ``buildout.cfg`` so that we do not have
+to repeat most sections but the ``parts`` in ``[buildout]`` have to be
+listed.
+
+We need, however, not everything with a ZEO-deploy that is listed in a
+default buildout. We might do not need docs, no profiling, etc. Also a
+regular non-ZEO kofactl might not make to much sense. Therefore all
+this might be subject to changes.
Index: in/waeup.aaua/trunk/README.txt
===================================================================
--- /main/waeup.aaua/trunk/README.txt	(revision 11375)
+++ 	(revision )
@@ -1,395 +1,0 @@
-Installation of Kofa on Linux production system
-###############################################
-
-.. note:: `waeup.kofa` and its custom packages
-          might not work with Python > 2.7
-          currently. Use of Python 2.7 is recommended.
-          The installation is described for Linux-based computers.
-
-Part 1: Deploying Kofa as a single Zope client install
-******************************************************
-
-Prerequisites
-=============
-
-The Kofa packages are based on `Grok`_, which is a Python
-framework for agile webapplication development. Grok itself is based
-on `Zope`_.
-
-.. _Grok: http://grok.zope.org/
-
-.. _Zope: http://www.zope.org/
-
-Both, Grok and Zope, are written in Python (with parts written in
-C). You therefore need `Python`_ installed.
-
-.. _Python: http://www.python.org/
-
-Note, that you also need the Python header files and a compiler to
-compile the parts written in C.
-
-To deploy Kofa most easily, we use `zc.buildout`_
-
-.. _zc.buildout: http://cheeseshop.python.org/pypi/zc.buildout
-
-
-Preparing the system
-====================
-
-To create a working copy of Kofa we recommend use of
-`virtualenv`. You, however, need also some basic libraries, a C
-compiler and some things more.
-
-What you need (Debian/Ubuntu package names in brackets):
-
-* Python 2.7 (python2.7)
-
-* Python 2.7 development files (python2.7-dev)
-
-* A C-Compiler (gcc)
-
-* The C library development files (libc6-dev)
-
-* A subversion client (svn)
-
-* enscript (enscript) [optional]
-
-  This is only needed if you want test coverage reports.
-
-All these packages can be installed on Debian systems like this::
-
-  # apt-get install python2.7 python2.7-dev python2.7-dbg \
-                    gcc libc6-dev svn enscript
-
-Afterwards you should be able to enter::
-
-  $ python2.7
-
-at the commandline and get a Python prompt. Quit the interpreter
-pressing <CTRL-D>.
-
-
-Installing `virtualenv`
-=======================
-
-We recommend use of `virtualenv` to create Python sandboxes where you
-can run your code without touching any other installations.
-
-If you don't already have ``easy_install`` available, you can find the
-script to set it up on the `PEAK EasyInstall page`_.
-
-.. _`PEAK EasyInstall page`: http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install
-
-You need to download `ez_setup.py`_. Then, you run it like this to
-install ``easy_install`` into your system Python::
-
-  $ sudo python2.7 ez_setup.py
-
-.. _`ez_setup.py`: http://peak.telecommunity.com/dist/ez_setup.py
-
-This will make ``easy_install`` available to you.
-
-.. note:: Sometimes you have ``easy_install`` installed but you need a
-          newer version of the underlying setuptools infrastructure to
-          make Grok work. You can upgrade setuptools with::
-
-            $ sudo easy_install -U setuptools
-
-Now you can install `virtualenv` by doing (as root)::
-
-  # easy_install-2.7 virtualenv
-
-This step will fetch all needed sources from the internet and install
-`virtualenv` locally in your Python2.7 installation.
-
-
-Creating a sandbox
-==================
-
-This step is only necessary (and recommended) if you installed
-`virtualenv` before.
-
-As a normal user you now can create a sandbox for your upcoming work
-by::
-
-  $ virtualenv --no-site-packages mysandbox
-
-where ``mysandbox`` is a directory in the filesystem where your
-sandbox will be created. `virtualenv` will also create this directory
-for you.
-
-By passing the ``no-site-packages`` switch we tell `virtualenv` to
-provide us a clean environment without any extra-packages installed
-systemwide.
-
-You now can activate the sandbox by doing::
-
-  $ source mysandbox/bin/activate
-
-You will notice that the input prompt changes.
-
-To deactivate the sandbox at any time, enter::
-
-  (sandbox27)$ deactivate
-
-and the prompt will be the same as before the activation.
-
-For the following steps make sure the sandbox is active.
-
-
-Creating a working place
-========================
-
-In the sandbox we now create our real working
-environment. To do this, we change to the sandbox and checkout the
-sources of Kofa from the subversion server::
-
-  (sandbox27)$ cd mysandbox/
-  (sandbox27)$ svn co https://svn.waeup.org/repos/main/waeup.kofa/trunk kofa-trunk
-
-where ``kofa-trunk`` is only a name we've chosen here to make clear
-where the sources come from. In this case we are installing the Kofa base
-package.
-
-The command should fetch the Kofa base package sources for you and
-put it in the directory ``kofa-trunk/``.
-
-Now enter the new directory::
-
-  (sandbox27)$ cd kofa-trunk
-
-
-Preparing the build
-===================
-
-In the sources directory (``kofa-trunk/``) you have to prepare the
-project to fetch needed components (eggs), compile C-code parts,
-etc. This steip will not touch any external projects::
-
-  (sandbox27)$ python bootstrap.py
-
-This will generate some directories and the ``buildout`` script in
-``bin/`` for us. This step must be executed only once for each
-instance.
-
-You can now deactivate the sandbox::
-
-  (sandbox27)$ deactivate
-
-Now we can do the real build by triggering::
-
-  $ bin/buildout
-
-If this is your first install of some Grok-related project, this step
-will need some time as lots of sources have to be fetched, many
-components must be compiled, etc.
-
-This step must be redone whenever you change something in
-``buildout.cfg`` or ``setup.py``.
-
-Note that if you have more than one sandbox for a Zope-based web
-application, it will probably make sense to share the eggs between the
-different sandboxes.  You can tell ``zc.buildout`` to use a central
-eggs directory by creating ``~/.buildout/default.cfg`` with the
-following contents::
-
-    [buildout]
-    eggs-directory = /home/bruno/buildout-eggs
-
-
-Start the instance
-==================
-
-You should be able now to start the created instance by doing::
-
-   $ bin/zopectl fg
-
-Alternatively you can do:
-
-    $ bin/paster serve parts/etc/deploy.ini
-
-The port numbers where Kofa is running on your server are defined in
-buildout.cfg under [kofa_params].
-
-If you now point a browser to the right port on your server, for example ::
-
-   localhost:8080
-
-you should get a login pop-up, where you can login as superuser with
-``grok`` and ``grok`` as username/password (Kofa base package only!).
-
-You can stop the instance by pressing <CTRL-C>.
-
-If you are connected and logged in,
-you should be able to add the grok-based applications
-(such as ``University``) from the menu.
-
-Add an instance of ``University`` and click on the link next to the
-then visible entry in the list of installed applications.
-
-Running the tests
-=================
-
-The tests are easily run by executing the test runner that's
-installed in the ``bin`` directory::
-
-    $ bin/test
-
-
-Part 2: Deploying Kofa as ZEO install
-*************************************
-
-Each ZEO install consists of at least one ZEO server and normally two
-or more ZEO clients. While the ZEO server is meant to manage the ZODB
-database for clients, the clients connect to the outside world, listen
-for request and do the real dataprocessing.
-
-We prepared a `buildout` configuration that sets up one server
-configuration and two client configs. This configuration is in
-``buildout-zeo.cfg``.
-
-Generating the ZEO setup
-========================
-
-To install Kofa ZEO-based you can run `buildout` with the given
-(or your own) configuration file like this::
-
-  $ ./bin/buildout -c buildout-zeo.cfg
-
-This should generate all scripts necessary to run servers, clients,
-etc.
-
-Starting ZEO servers and clients
-================================
-
-First start the server::
-
-  $ ./bin/zeo_server start
-
-Clients can be started by doing::
-
-  $ ./bin/zeo_client1 start
-  $ ./bin/zeo_client2 start
-
-This will start both clients in daemon mode.
-
-Instead of ``start`` you can, as usually, start an instance in
-foreground (``fg``), etc. You know the drill.
-
-
-Manually starting ZEO clients
-=============================
-
-This is normally not neccessary.
-
-``zeo_clientN`` scripts are basically wrappers around calls to
-``bin/paster``. You can bypass this wrapper and start a client
-'manually' like this::
-
-  $ ./bin/paster serve --pid-file var/zeo1.pid --daemon \
-        pars/etc/zeo1.ini
-
-It is important to give a pid-file as paster otherwise can not start
-different clients (they would all refer to the same pid file
-`paster.pid` and refuse to start after the first client was started).
-
-
-Setup (paramters, ports, etc.)
-==============================
-
-By default the server will listen on port 8100 for requests from
-localhost (not: from the outside world).
-
-You can change ZEO server settings in the ``[zeo_server]`` section
-of ``buildout-zeo.conf``. Run `buildout` afterwards.
-
-The clients will listen on port 8081 and 8082. You can change settings
-in ``etc/zeo1.ini.in`` and ``etc/zeo2.ini.in`` respectively. Run
-buildout after any change.
-
-If you want to change the paster wrapper for any zeo client, you can
-edit ``etc/zeo1.conf`` and/or ``etc/zeo2.conf``. Run buildout
-afterwards.
-
-
-Creating new clients
-====================
-
-You want more clients to be created by buildout? Easy. Three steps are
-neccessary.
-
-1. Create config files in etc/
-------------------------------
-
-Each client needs two configuration files:
-
-  - ``etc/zeoN.conf``
-       configuring the paster wrapper
-
-  - ``etc/zeoN.ini``
-       configuring the runtime config, ports, etc.
-
-Just copy over these files from the already existing zeo1/zeo2 files
-and replace ``zeo1`` or ``zeo2`` with your new name.
-
-2. Update buildout-zeo.cfg
---------------------------
-
-Here, inside ``buildourt-zeo.cfg`` also three steps are needed.
-
-* 2.1. Create new .ini and .conf entries
-
-  The .conf and .ini files in etc/ are only templates that have to be
-  generated in their really used final location. In buildout-zeo.cfg
-  you can care for this by creating a new ``[zeoN_ini]`` and
-  ``[zeoN_conf]`` option (replacing ``N`` with a number, of course).
-
-  Just copy over existing entries and replace the mentions of ``zeo1``
-  or ``zeo2`` by your ``zeoN``.
-
-* 2.2. Create a new ``zeo_clientN`` entry
-
-  Then you have to create an entry that will generate the
-  ``zeo_clientN`` script. Again, just copy over an existing
-  ``[zeo_client1]`` entry and replace ``1`` withg your client number.
-
-* 2.3. Register the new sections in ``[buildout]`` section
-
-  When done with the above: add the new section in ``[buildout]``::
-
-    [buildout]
-      ...
-      <old entries...>
-      ...
-      zope_conf_zeo_5
-      zeo5_ini
-      zeo_client5
-
-  depending on how you named your new sections.
-
-3. Rerun ``buildout``
----------------------
-
-When adding or removing client/server instances, make sure to stop all
-running servers/clients before rerunning buildout.
-
-To activate the new setup, rerun buildout::
-
-  $ bin/buildout -c buildout-zeo.cfg
-
-This should generate any new clients and remove older ones or just
-update configuration files.
-
-
-Considerations
-==============
-
-There are some things in the current buildout-zeo.cfg we might do not
-want. It extends the regular ``buildout.cfg`` so that we do not have
-to repeat most sections but the ``parts`` in ``[buildout]`` have to be
-listed.
-
-We need, however, not everything with a ZEO-deploy that is listed in a
-default buildout. We might do not need docs, no profiling, etc. Also a
-regular non-ZEO kofactl might not make to much sense. Therefore all
-this might be subject to changes.
