Remove guide from dashboard and link to wikiFix for FS#10647

4 files changed, 2 insertions, 173 deletions

diff --git a/devel/views.py b/devel/views.py
index d825e31d..cecfe1a1 100644
--- a/devel/views.py
+++ b/devel/views.py
@@ -80,13 +80,6 @@ def change_profile(request):
             return HttpResponseRedirect('/devel/')
     return render_response(request, 'devel/profile.html', {'errors':errors,'email':request.user.email})
 
-def guide(request):
-    t = loader.get_template('devel/pkgmaint_guide.txt')
-    c = Context()
-    return HttpResponse(t.render(c), mimetype="text/plain")
-    #return render_response(request, 'devel/pkgmaint_guide.txt',
-    #                       mimetype='text/plain')
-
 def siteindex(request):
     # get the most recent 10 news items
     news  = News.objects.order_by('-postdate', '-id')[:10]
diff --git a/templates/devel/index.html b/templates/devel/index.html
index 8c621cc5..33db1bf1 100644
--- a/templates/devel/index.html
+++ b/templates/devel/index.html
@@ -89,7 +89,8 @@
 				{% endif %}
 					<a href="/packages/?maint=0">Orphan Packages</a><br />
 					<br />
-					<a href="/devel/guide/">Package Maintainer's Guide</a><br />
+					<a
+                        href="http://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager">Package Maintainer's Guide</a><br />
 				</td><td style="vertical-align: top">
 				{% if pkgs %}
 					<h4>My Flagged Packages:</h4>
diff --git a/templates/devel/pkgmaint_guide.txt b/templates/devel/pkgmaint_guide.txt
deleted file mode 100644
index 85106eab..00000000
--- a/templates/devel/pkgmaint_guide.txt
+++ /dev/null
@@ -1,164 +0,0 @@
-=============================================================================
-            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 $
diff --git a/urls.py b/urls.py
index 99526efc..fc544c74 100644
--- a/urls.py
+++ b/urls.py
@@ -29,7 +29,6 @@ urlpatterns = patterns('',
     (r'^devel/$',          'archweb_dev.devel.views.index'),
     (r'^devel/notify/$',   'archweb_dev.devel.views.change_notify'),
     (r'^devel/profile/$',  'archweb_dev.devel.views.change_profile'),
-    (r'^devel/guide/$',    'archweb_dev.devel.views.guide'),
 
     (r'^wiki/([A-Z]+[A-z0-9 :/-]+)/$',      'archweb_dev.wiki.views.page'),
     (r'^wiki/edit/([A-Z]+[A-z0-9 :/-]+)/$', 'archweb_dev.wiki.views.edit'),