Modified render_template and renamed it to render_response (consistent with

archweb_pub conventions).
Moved pkgmaint_guide to a template.

1 files changed, 164 insertions, 0 deletions

diff --git a/templates/devel/pkgmaint_guide.txt b/templates/devel/pkgmaint_guide.txt
new file mode 100644
index 0000000..85106ea
--- /dev/null
+++ b/templates/devel/pkgmaint_guide.txt
@@ -0,0 +1,164 @@
+=============================================================================
+            THE QUICK AND DIRTY ON HOW TO BE A PACKAGE MAINTAINER
+=============================================================================
+                                             questions to jvinet@zeroflux.org
+
+1. Follow Package Guidelines
+
+   Package guidelines can be found in the Arch Linux documentation.
+   Please follow them closely.
+
+2. How To Use CVS
+
+   The example commands below assume the module 'extra'.
+
+   2.1  Make sure your CVSROOT environment variable is set properly.  If the
+        CVS repository is on the same box:
+          # export CVSROOT=/home/cvs-extra
+
+        If you want to access the repository from the different box via SSH:
+          # export CVS_RSH=ssh
+          # export CVSROOT=:ext:user@cvs.archlinux.org:/home/cvs-extra
+
+   2.2  Checkout the repository.  This will download the entire repository to
+        your local machine:
+          # cvs co extra
+
+   2.3  Updating the repository.  This syncs your local repository with the
+        master.  You should do this often, especially if other people could be
+        working on the same repository.
+          # cd extra
+          # cvs -q update -d
+
+   2.4  Adding files/directories to the repository.  When you want to add a new
+        package you should create a directory under the respective category and
+        place the new PKGBUILD in it.  For example, to add fvwm to the repo:
+          # cd extra/x11
+          # mkdir fvwm
+          # cd fvwm
+          # cp /var/abs/PKGBUILD.proto ./PKGBUILD
+          <edit, test, build, etc>
+          # cd ..
+          # cvs add fvwm
+          # cvs add fvwm/PKGBUILD
+
+   2.5  Committing changes. Files are not written to the master repository until
+        you commit.  Never forget to commit!
+          # cd extra
+          # cvs commit
+ 
+        This will find all modified files, then throw you into vi where you can
+        add a log message describing your changes.  Save and exit from vi when
+        you're done and cvs will update the files in the master repository.
+
+   2.6  Removing files.  If you need to remove a file (eg, an old patch that
+        isn't needed anymore), you can do the following:
+          # cd extra/x11/fvwm
+          # rm old.patch
+          # cvs remove old.patch
+          # cvs commit -m "removed old.patch" old.patch
+        also remove the CURRENT/STABLE tags from the file so it does not appear
+        in ABS any more:
+          # cvs tag -d CURRENT old.patch
+ 
+        Don't forget to commit afterwards!  Remember that no changes are made
+        to the master until you commit.
+
+   2.7  Removing directories cannot be done easily.  If you really need to
+        remove a directory, email the sysadmin (Judd) and I'll help you out.
+
+   2.8  Tagging files.  Every file in CVS has tags associated with it, which
+        allows us to select certain versions of scripts.  The db generation
+        scripts will only look at files that are tagged as CURRENT, so you need
+        to tag all files after you commit them:
+          # cd extra/x11/fvwm
+          # cvs tag -c -F -R CURRENT
+
+        NOTE: When tagging, you should be sure to ONLY tag the updated files,
+        not the entire repository.  Otherwise, if parts of your checkout are
+        out-of-date, you may actually be tagging an OLDER version of a file,
+        reversing someone else's tag procedure.
+
+3. The Process
+
+   3.1  Checkout/update your local repository from cvs.archlinux.org
+   3.2  Make any changes you need to
+   3.3  Put your new packages in your local staging directory on archlinux.org.
+        Suggested syntax is: 
+          scp name-ver-rel.pkg.tar.gz you@archlinux.org:staging/extra/add
+   3.4  Commit your changes (section 2.5)
+   3.5  Update the CURRENT tags to new revisions (section 2.8)
+   3.6  Log in to archlinux.org and run the /arch/db-extra script, which
+        will re-generate the sync db and place it in /home/ftp/extra, then
+        move the new/updated packages from your staging directory to the
+        FTP tree.
+   3.7  Remove any older versions of packages from /home/ftp/extra to
+        save diskspace, they should be noted when the db generation script
+        finishes.
+
+   Make sure you do things in this order, mixing them up can break things
+   temporarily.  For example, if you remove older versions from the ftp
+   tree before you update the database or update the database before 
+   uploading new packages, arch users trying to download the package at 
+   that time will get "file not found" errors.
+
+4. Staging Directories
+
+   As mentioned in Section 3, packages need to be uploaded to the proper
+   staging directory before running a db generation script.  The staging
+   area (located in your home dir) looks like so:
+
+    staging
+    |-- arch
+    |   |-- add
+    |   `-- del
+    |-- extra
+    |   |-- add
+    |   `-- del
+    |-- testing
+    |   |-- add
+    |   `-- del
+    `-- unstable
+        |-- add
+        `-- del
+
+   As you can see, each repository has two staging directories: "add" and
+   "del".  When you want to add or update a package, you'll place it in the
+   "add" directory for the repository you're working in.  Then run the db-gen
+   script.
+   
+   When you want to remove a package, you will move the package OUT OF the FTP
+   directory (eg, /home/ftp/extra/os/i686/) and INTO the "del" directory for
+   the repository you're working in.  Once moved, you can run the db-gen
+   script -- it will see that the file has left the FTP tree and will remove
+   it from the package database.
+
+5. Miscellaneous Stuff
+
+   5.1  If you are creating a daemon you need to include an rc.d startup
+        script for it.  Look at /var/abs/daemons/esd for a simple example.
+   5.2  Please include a line that says '# $Id: pkgmaint_guide.txt,v 1.3 2006/10/05 20:52:01 judd Exp $' at the top of each
+        PKGBUILD.  This will be parsed by cvs during a commit, and replaced
+        with user/timestamp data.
+   5.3  Please do some rudimentary checks of the package before making it
+        'live'.  Try installing it and see if there are any file conflicts.
+        Check for dependencies by running 'ldd' against the binaries and
+        looking through the .so files it requires.  For example,
+        'ldd /usr/bin/gvim' returns a big list of libs, one of which is
+        libgtk-x11-2.0.so.0, so gtk2 should be one of the dependencies for
+        gvim.  Also, namcap is available in the extra repository.  Running it 
+        against a package will print dependancy warnings as well as possible
+        configuration problems.  Namcap is not the final word, if ldd or
+        runtime show otherwise, believe them instead.
+   5.4  When creating a package description for a package, do not include
+        the package name in a self-referencing way, as it is redundant.
+        For example, "Nedit is a text editor for X11" could be simplified to
+        "A text editor for X11".  Also try to keep the descriptions to ~80
+        characters or less.
+   5.5  When entering cvs log messages for new/upgraded packages, please use
+        these tags so they can be easily parsed for changelog generation:
+          if the package is upgrade use: 'upgpkg: pkgname newpkgver'
+          if the package is new use:     'newpkg: pkgname newpkgver'
+
+
+$Id: pkgmaint_guide.txt,v 1.3 2006/10/05 20:52:01 judd Exp $