r31 - / website
Joachim Breitner
nomeata@haydn.debian.org
Wed, 09 Jun 2004 09:44:44 -0600
Author: nomeata
Date: 2004-06-09 09:44:41 -0600 (Wed, 09 Jun 2004)
New Revision: 31
Added:
website/
website/announcement.txt
website/cvs.txt
website/goals.txt
website/header.txt
website/policy.txt
website/readme.txt
website/rules-template-noxs
website/subversion.pod
Log:
Imported Website Files
Added: website/announcement.txt
===================================================================
--- website/announcement.txt 2004-06-09 15:38:40 UTC (rev 30)
+++ website/announcement.txt 2004-06-09 15:44:41 UTC (rev 31)
@@ -0,0 +1,52 @@
+This is the announcement as it was sent to
+debian-devel-announce@lists.debian.org, Junauary the 7th. See also:
+http://lists.debian.org/debian-devel-announce/2004/debian-devel-announce-200401/msg00002.html
+
+
+Subject: Debian Perl Group founded
+
+At November 17th, a discussion about a common problem for Debian Perl
+developers was started on debian-perl@l.d.o. [1] Most developers often
+realize that modules available on CPAN are not included in the Debian
+archive. This hinders the packaging of Perl applications and other
+modules.
+
+After discarding the idea of automatically dumping all CPAN modules
+into the Debian archive, a collective effort to improve the packaging
+of Perl modules in Debian was proposed. This consists of creating new
+packages of needed Modules as well as of bugfixing and updating
+existing packages.
+
+This seems to be necessary, as even many of the Perl modules included
+in the unstable distribution of Debian are outdated. [2]
+
+These thoughts lead to the founding of the Debian Perl Group, defined
+through the following goals:
+ * Adopt orphaned Perl module packages.
+ * Handle the RFP of Perl modules.
+ * Document and improve the usage of tools like dh-make-perl.
+ * Help with bugs in Perl packages.
+ * Keeping Perl packages in the Debian archive as up-to-date as
+ possible.
+[An updated list of these goals is available here:
+http://pkg-perl.alioth.debian.org/goals.txt]
+
+An Alioth project [3] has been set up to coordinate the work. A draft
+for a policy has been created [4] and is currently under discussion.
+
+The first three new modules were packaged, checked and uploaded to the
+Debian Archive at January 6th. Some issues we will work on in the next
+weeks, especially orphaned packages, were submitted to our TODO list.
+
+This is an invitation for all interested developers to join us.
+
+
+The Debian Perl Group
+
+[1] http://lists.debian.org/debian-perl/2003/debian-perl-200311/msg00023.html
+[2] Leon Brocard assembled a list of outdated Perl modules with a script and
+ provided both the list and the script in
+ http://lists.debian.org/debian-perl/2003/debian-perl-200311/msg00043.html
+[3] http://alioth.debian.org/projects/pkg-perl
+[4] http://pkg-perl.alioth.debian.org/policy.txt
+
Added: website/cvs.txt
===================================================================
--- website/cvs.txt 2004-06-09 15:38:40 UTC (rev 30)
+++ website/cvs.txt 2004-06-09 15:44:41 UTC (rev 31)
@@ -0,0 +1,138 @@
+Debian Perl Group
+~~~~~~~~~~~~~~~~~
+
+CVS and packaging.
+
+Here I will document how I put the perl packages in our CVS, how I extracted
+them and so on. This grows organically and while I learn to use the tools
+(especially cvs-buildpackage, but also cvs), so any comments are welcome.
+
+##### Initial upload to cvs
+
+I configured cvs-buildpackage as follows:
+
+~/debian/pkg-perl $ grep ^[^#] ~/.cvsdeb.conf
+conf_rootdir=~/debian/cvs/Packages # set to whatever you like
+conf_prefix=packages # do set that. it's a subdir in our CVS
+ tree, to make separate it from other
+ stuff [1]
+
+Then I just ran:
+# cvs-inject libparse-debian-packages-perl_0.01-1.dsc
+
+Next, I defined cvs modules for the packages, besace the cvs-* tools somehow
+preferred that. It's just this:
+libparse-debian-packages-perl packages/libparse-debian-packages-perl
+libmodule-packaged-perl packages/libmodule-packaged-perl
+libcpan-distnameinfo-perl packages/libcpan-distnameinfo-perl
+
+##### Building the package
+
+It's as easy as this:
+# cvs-buildpackage libparse-debian-packages-perl -rfakeroot -uc -us
+(the last 3 options are for dpkg-buildpackage)
+
+This builds the package in the directory "$conf_rootdir/packagename", that we
+set a bit further up, that's where we can find it afterwards. That was easy!
+
+Actually, there is a cvs-debuild, which calls debuild, which is better :-)
+Also, the -k option is handy if you're not the one in the changelog field:
+# cvs-debuild libmodule-packaged-perl -k"4743206C"
+
+
+##### Checking out from CVS for modifications
+
+Just a normal CVS checkout. I had CVSROOT set (see
+http://alioth.debian.org/scm/?group_id=1396), so I just ran
+# cvs checkout libparse-debian-packages-perl
+and voila, there is the whole libparse-debian-packages-perl with debian and
+upstream files in my directory - ready to be hacked on.
+
+##### Changing files
+
+As I understand it, you can change debian files and upstream files the same
+way - it gets handled just as if it were a local project, and
+dpkg-buildpackage will worry about that later.
+
+Ok, I'll find a simple change that would make nobody angry...
+
+Let's just set the Maintainer field. I edited the file as ususal, and then
+ran:
+
+# cvs commit -m 'changed maintainer field to Debian Perl Group'
+
+Which worked like a charm.
+
+Don't forget to set the cvs tag, if these changes should go with the next
+upload. Do this with the proper version tag and package name:
+
+# cvs rtag -a -F debian_version_0_79-1 libboulder-perl
+
+We have to use rtag so that deleted files will get their tag removed. rtag
+requires a module name as the argument. (Don't use ".", that will tag the
+whole cvs directory)
+
+##### New upstream version
+
+Looks like
+http://search.cpan.org/CPAN/authors/id/L/LB/LBROCARD/Module-Packaged-0.71.tar.gz
+just arrived. Let's update our package then... *reading the docs*
+
+I start by putting the file in
+~/debian/cvs/Packages/libmodule-packaged-perl/libmodule-packaged-perl_0.71_orig.tar.gz
+
+This is cvs-buildpackages' work dir, not the one where I hack around. (Those
+two directories are independant).
+
+Then I run
+# cvs-upgrade libmodule-packaged-perl 0.71
+This seemed to have create a new verdor branch or something, that I have to
+integrade (cvs-update spits out some instructions).
+
+I go to my hacking work directory and run
+# cvs update -d -jupstream_version_0_67 -jupstream_version_0_71
+This updates a few files, merging differences, no error messages. I guess, if
+there were conflicts (we changed the upstream files, and they changed the
+same spot), I'd have to resolve them now.
+
+Also, If there were new files added or removed, I should have used
+/usr/share/doc/cvs-buildpackage/cvs-co-upgrade.gz to care for that. I just
+hoped for now, guess this is a TODO for this file.
+
+Now I have to do these steps, as cvs-update told me:
+
+# cd libmodule-packaged-perl
+# vi debian/changelog # (I used 'dch -v 0.71-1 New Upstream Version')
+# cvs commit -m'New upstream source'
+# cvs rtag -F debian_version_0_71-1 libmodule-packaged-perl # tagging for cvs-buildpackage (note the -1)
+
+Now I delete the directory and checked it out again, and voila, new versions
+of everything.
+
+Building with cvs-buildpackage:
+# cvs-buildpackage libmodule-packaged-perl -rfakeroot -uc -us
+worked and gave me libmodule-packaged-perl_0.71-1_all.deb
+
+That's it. Guess we can work with that.
+
+##### Other useful cvs commands
+
+# cvs-debc #ran in your work directory
+Displays the contents of and other infos about the just built package.
+
+# cvs-debi # ran in your work directory
+Installes the just build package using debpkg (see debi(1) and debpkg(1))
+
+##### Summary
+
+cvs-buildpackage seems not to change the developing process - just regulary
+update and commit and build with cvs-buildpackage, and the rest ist just the
+same.
+
+
+[1] This only seems to touch cvs-inject. Can someone comment on that?
+
+#####
+$Id: cvs.txt,v 1.11 2004/01/10 11:51:27 nomeata Exp $
+
+vim:tw=77
Added: website/goals.txt
===================================================================
--- website/goals.txt 2004-06-09 15:38:40 UTC (rev 30)
+++ website/goals.txt 2004-06-09 15:44:41 UTC (rev 31)
@@ -0,0 +1,14 @@
+Debian Perl Group
+~~~~~~~~~~~~~~~~~
+
+These are our goals:
+
+We want to constantly improve the coverage of available perl modules in debian.
+Specifically, we aim to:
+ * Adopt orphaned Perl module packages.
+ * Handle the RFP of Perl modules.
+ * Document and improve the usage of tools like dh-make-perl.
+ * Help with bugs in Perl packages.
+ * Keeping Perl packages in the Debian archive as up-to-date as possible.
+
+$Id: goals.txt,v 1.6 2004/01/07 14:16:27 he-guest Exp $
Added: website/header.txt
===================================================================
--- website/header.txt 2004-06-09 15:38:40 UTC (rev 30)
+++ website/header.txt 2004-06-09 15:44:41 UTC (rev 31)
@@ -0,0 +1,16 @@
+Debian Perl Group
+~~~~~~~~~~~~~~~~~
+
+* Contact Information:
+
+We use
+ http://alioth.debian.org/projects/pkg-perl/
+ for internal TODO lists, CVS and this webspace
+ http://bugs.debian.org/
+ for bugtracking of the packages
+ debian-perl@lists.debian.org
+ for internal communication as well as the contact place for others.
+ pkg-perl-maintainers@lists.alioth.debian.org
+ is for the Maintainer field and the automatic mails that come with that.
+
+
Added: website/policy.txt
===================================================================
--- website/policy.txt 2004-06-09 15:38:40 UTC (rev 30)
+++ website/policy.txt 2004-06-09 15:44:41 UTC (rev 31)
@@ -0,0 +1,73 @@
+Debian Perl Group
+~~~~~~~~~~~~~~~~~
+
+Project Internal Policy
+
+Here we document how we do stuff internally. This file is of course
+work in progress and will probably always be.
+
+0) Content
+
+ 1) Mandatory mailing lists and such
+ 2) Changelog Handling and CVS tagging
+ 3) Release Process
+
+
+1) Mandatory mailing lists and such
+
+All members of our group should be subscribed to
+debian-perl@lists.debian.org and read this list (at least skim all
+messages for Debian Perl Group related stuff).
+Additionally, every members should be subscribed to
+pkg-perl-maintainers@lists.alioth.debian.org to receive bug reports
+and similar. (Is there anything the PTS would send that the Maintainer
+e-mail-address wouls not recieve?)
+
+All members are encouraged to have all our packages installed. They
+are also encouraged to check our webspace and the tracker on alioth
+regulary. (Hint: Have our CVS checked-out somewhere and run
+"cvs update" from time to time.) And there is
+pkg-perl-cvs-commits@lists.alioth.debian.org where anybody can watch
+us work.
+
+2) Changelog Handling and CVS tagging
+
+We use the debian revision to count our releases to the debian
+archive, not internal steps. So if and only if you do the first change
+after a release, you add another debian/changelog entry (dch -i).
+Since your name and e-mail will then be in there, you have to check
+that you are listed in Uploaders: in debian/control (otherwise katie
+or whoever will think that you are doing a NMU).
+
+If someone else changed something that has to be noted in
+debian/changelog, he just adds a line to the current entrry (dch -a).
+He should not put his name there - the user does not care and we can
+always check the CVS log.
+
+After each changes (and to make sure, before you build the package),
+you should run something like
+# cvs tag -F debian_version_1_12-3
+in the top directory of your working copy. The -F is to move the tag
+if it has be set already. 1_12 is the upstream version (replace points
+and stuff with _), and 3 the debian version (if for some reason this is
+a NMU, then name this 3_1). This is the naming scheme from
+cvs-buildpackage. The version as to correspond exactly with the one
+in the current entry in debian/changes.
+
+Hint: use
+# cvs status -v debian/changelog
+to see the already-set tags, in case you are unsure about the naming
+scheme or wheter your taggin actually worked.
+
+3) Release Process
+
+If you are a full DD, upload but be prepared to receive (at least
+parts of) the blame. If you are not, some DD in the Group will surely
+sponser the package. He will check the package first, too, but make
+sure he has no reason to complain. Feel free to use the "Packages to
+Upload" tracker for finding a sponsor.
+
+Always feel free to ask other to check a package if in doubt.
+
+$Id: policy.txt,v 1.4 2004/03/04 18:40:57 nomeata Exp $ vim:tw=70
+
Added: website/readme.txt
===================================================================
--- website/readme.txt 2004-06-09 15:38:40 UTC (rev 30)
+++ website/readme.txt 2004-06-09 15:44:41 UTC (rev 31)
@@ -0,0 +1 @@
+PS: We are not about the perl interpreter.
Added: website/rules-template-noxs
===================================================================
--- website/rules-template-noxs 2004-06-09 15:38:40 UTC (rev 30)
+++ website/rules-template-noxs 2004-06-09 15:44:41 UTC (rev 31)
@@ -0,0 +1,78 @@
+#!/usr/bin/make -f
+
+# This debian/rules file is provided as a template for normal perl
+# packages. It was created by Marc Brockschmidt <marc@dch-faq.de> for
+# the Debian Perl Group (http://pkg-perl.alioth.debian.org/) but may
+# be used freely wherever it is useful.
+
+PACKAGE=$(shell dh_listpackages)
+
+ifndef PERL
+PERL = /usr/bin/perl
+endif
+
+TMP =$(CURDIR)/debian/$(PACKAGE)
+
+# Allow disabling build optimation by setting noopt in
+# $DEB_BUILD_OPTIONS
+CFLAGS = -Wall -g
+ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
+ CFLAGS += -O0
+else
+ CFLAGS += -O2
+endif
+
+build: build-stamp
+build-stamp:
+ dh_testdir
+
+ $(PERL) Makefile.PL INSTALLDIRS=vendor
+ $(MAKE) OPTIMIZE="$(CFLAGS)"
+
+ touch build-stamp
+
+clean:
+ dh_testdir
+ dh_testroot
+ -$(MAKE) distclean
+ dh_clean build-stamp install-stamp
+
+install: install-stamp
+install-stamp: build-stamp
+ dh_testdir
+ dh_testroot
+ dh_clean -k
+
+ $(MAKE) test
+ $(MAKE) install DESTDIR=$(TMP) PREFIX=/usr
+
+ #As this is a architecture independent package, we are not supposed to install
+ #stuff to /usr/lib. MakeMaker creates the dirs, we delete them from the deb:
+ rmdir --ignore-fail-on-non-empty --parents $(TMP)/usr/lib/perl5
+
+ touch install-stamp
+
+binary-arch:
+# We have nothing to do by default.
+
+binary-indep: build install
+ dh_testdir
+ dh_testroot
+# dh_installdocs
+# dh_installexamples
+ dh_perl
+ dh_installchangelogs
+ dh_link
+ dh_strip
+ dh_compress
+ dh_fixperms
+ dh_installdeb
+ dh_gencontrol
+ dh_md5sums
+ dh_builddeb
+
+source diff:
+ @echo >&2 'source and diff are obsolete - use dpkg-source -b'; false
+
+binary: binary-indep binary-arch
+.PHONY: build clean binary-indep binary-arch binary
Property changes on: website/rules-template-noxs
___________________________________________________________________
Name: svn:executable
+
Added: website/subversion.pod
===================================================================
--- website/subversion.pod 2004-06-09 15:38:40 UTC (rev 30)
+++ website/subversion.pod 2004-06-09 15:44:41 UTC (rev 31)
@@ -0,0 +1,312 @@
+=head1 NAME
+
+Debian Perl Group Subversion Guide
+
+=head1 INTRODUCTION
+
+This guide describes the procedures that the Debian Perl Group
+developers use to upload packages to the Subversion (SVN) repository
+Debian provides to them.
+
+It will describe how to upload an initial package, how to update the
+packages, how to build them and how to upgrade them.
+
+This is a work in progress. Please send any comments or ideas to
+<debian-perl@lists.debian.org>.
+
+=head1 INDEX
+
+=over 4
+
+=item 1. The Tools
+
+=item 2. Repository Anatomy.
+
+=item 3. Initial Upload
+
+=item 4. Building the Package
+
+=item 5. Tagging and Releasing
+
+=item 6. Upstream Upgrade
+
+=item 7. Hints and tricks
+
+=back
+
+=head1 1. The Tools
+
+This section will describe what tools are available and what they do.
+This section is a work in progress. Please send any comments or ideas
+on how to improve this section to <debian-perl@lists.debian.org>.
+
+Most of the tools you will be using will come from either the
+B<svn-buildpackage> or the B<subversion> packages. These are their
+contents:
+
+=over 4
+
+=item svn-buildpackage
+
+The svn-buildpackage contains the following tools:
+
+=over 4
+
+=item * svn-inject
+
+Like we said, B<svn-inject> is used to insert the source of a package
+into the repository. It operates on the .dsc file associated with the
+source files. It checks in the package and upstream code in the
+correct locations in SVN. This tool should be used when a new package
+is put in the care of the Perl Group.
+
+=item * svn-buildpackage - Like dpkg-buildpackage, only SVN aware.
+
+At some point in time, the package will have to be uploaded for
+inclusion in unstable. The packages that reside in SVN have to be
+built for that. However, dpkg-buildpackage doesn't play nice with SVN
+checkout directories. Luckily, B<svn-buildpackage> does. Use
+svn-buildpackage in a checkedout directory.
+
+=item * svn-upgrade - Used to upgrade a checkout to a new upstream version.
+
+TODO
+
+=back
+
+=item subversion
+
+The tool you will mostly be using is the B<svn> tool which resides
+here. This is the tool similar to B<cvs> in that it is used to add
+files, remove files, move files, etc. It is also used for checkout,
+export and commit commands, amongst others.
+
+=back
+
+=head1 2. Repository Anatomy
+
+The structure of a standard Subversion repository is a follows:
+
+ trunk/
+ tags/
+ branches/
+
+Obviously, trunk/ is where the trunk lives, tags/ is where tags live
+(they are a little different in SVN than in CVS, please see
+http://svnbook.red-bean.com/) and branches is where branches live.
+
+We will have quite a few perl modules over time, so we will start of
+with splitting our repository into subrepositories:
+
+ libfile-touch-perl/trunk/
+ libfile-touch-perl/tags/
+ libfile-touch-perl/branches/
+ libperl6-export-perl/trunk/
+ libperl6-export-perl/tags/
+ libperl6-export-perl/branches/
+
+Currently, branches/ is where the upstream code resides. Various tools
+use this branch to download original tarballs to generate .diff.gz
+files when building. This is also the only branch we will be using
+for now, but time will tell.
+
+In tags/, we tag all of our releases like we do in CVS, like so:
+
+ libfile-touch-perl/tags/debian_version_0_04-1/
+
+If we would want to checkout libfile-touch-perl_0.04-1, we could
+simply checkout the location of the tag. More on that in the SVN
+documentation and in this document later on.
+
+=head1 3. Initial Upload
+
+The upload procedure is simple. Once you have the source to the
+package (.orig.tar.gz, .diff and .dsc), all you have to do is:
+
+ svn-inject \
+ libfile-touch-perl_0.04-1.dsc \
+ svn+ssh://user@svn.debian.org/svn/pkg-perl/
+
+You might want to upload your public DSA key to the svn server before
+starting this procedure, see hints and tricks below.
+
+svn-inject will now start doing the following:
+
+=over 4
+
+=item 1. Start a new package tree in SVN.
+
+=item 2. Upload the orig.tar.gz to C<branches/upstream>.
+
+=item 3. Checkout this upstream version into a working directory.
+
+=item 4. Patch the working directory version with your .diff.gz.
+
+=item 5. Upload this new debianized version to C<trunk>.
+
+=back
+
+We now have to tag the release, but only if this is a definite
+version. Hack away at the source, commit, and if you're done, tag the
+release:
+
+ svn copy \
+ svn+ssh://user@svn.debian.org/svn/pkg-perl/libfile-touch-perl/trunk/ \
+ svn+ssh://user@svn.debian.org/svn/pkg-perl/libfile-touch-perl/tags/debian_version_0_04-1
+
+More about tagging later.
+
+=head1 4. Building the package
+
+=head2 4.1 Building trunk
+
+If we would want to checkout a release for building, we would carry
+out the following command:
+
+svn checkout svn://svn.debian.org/pkg-perl/libcgi-safe-perl/trunk/ .
+
+This checks out the trunk in to the current directory. Now, type:
+
+ svn-buildpackage [-rfakeroot] [-kyourkey] [-uc] [-us]
+
+This will try to build the package and will try the following trying
+to do so:
+
+=over 4
+
+=item 1. Extract the current version from debian/changelog
+
+=item 2. Export the current checkout to ../build-area/package-version
+
+=item 3a. Check for the availability of .orig.tar.gz source tarball
+
+=item 3b. Check for the availability of .orig sourcedir
+
+=item 4. build the package using dpkg-buildpackage
+
+=item 5. Clean the build tree and delete the exported checkout
+
+=item 6. Things will be done in ../build-area/
+
+=back
+
+Note that if there were previous uploads with the same upstream version
+to the debian archive that were not built with svn-buildpackage, the
+debian archive scripts would most likely complain if you build your
+package with the .orig.tar.gz that svn-buildpackage creates from the svn
+repository. To avoid this, put the .orig.tar.gz file from the debian
+archive in you build directory (manually or just using apt-get source).
+If you upload the the first and subsequential packages of an upstream
+version, you don't have to worry about this.
+
+=head2 4.2 Building an already tagged release
+
+This is a little trickier than building the trunk. First check out the tag:
+
+ svn co svn://svn.debian.org/pkg-perl/libcgi-safe-perl/tags/debian_version_0_04-1 \
+ libcgi-safe-perl_0.04-1
+
+Now, if we want a full build, we need the sources. Therefore, we have
+to sortof hack around some limitations of svn-buildpackage. We need to
+add a line to libcgi-safe-perl_0.04-1/.svn/deb-layout:
+
+upsCurrentUrl=svn://svn.debian.org/pkg-perl/libnet-imap-simple-perl/branches/upstream/0.93
+
+This enables svn-buildpackage to find upstream sources correctly.
+
+If you sign the key, the package is ready for upload with dput et. al.
+
+=head1 5. Tagging and Releasing
+
+We will need to be able to fetch the source to any debian release that
+is out there. This is why we have to tag our repository after every
+package release. Like we said before, tagging is not exactly the same
+as in CVS. In CVS, the versionnumber for every tagged file is aliased
+with that tag. That way, version 1.1.1 is aliased debian_version_0.1-1
+and version 1.1.2 is aliased debian_version_0.1-2, for example. In
+SVN, this works differently.
+
+In SVN, we copy the state of the B<tree> to a new directory called
+tags. This way, file revisions aren't aliased, we simply copy the tree
+in its current form to a different location just like you would in a
+regular filesystem. SVN does this cleverly, so you can keep track of
+logentries and the copied tree doesn't take up any extra space on
+disk.
+
+It works like this:
+
+ svn copy \
+ svn://user@svn.debian.org/svn/pkg-perl/libfile-touch-perl/trunk/ \
+ svn://user@svn.debian.org/svn/pkg-perl/libfile-touch-perl/tags/debian_version_0.04-1
+
+You don't need a checkout of the SVN tree to do this. It even works
+faster if you don't have one. It can execute these commands over the
+network.
+
+Whenever you would feel like checking out one debian release, just
+check out the directory you copied earlier.
+
+ svn export \
+ svn://user@svn.debian.org/svn/pkg-perl/libfile-touch-perl/tags/debian_version_0.04-1 \
+ libfile-touch_0.04-1
+
+Now, dpkg-buildpackage away!
+
+B<NB!> Never modify files in the tag directory. If you tag by
+mistake, just delete the directory and copy a different revision of
+the trunk/whatever.
+
+You can tag an older revision by using the -r switch:
+
+ svn copy -r 53 svn://.../pkg-perl/libfile-touch-perl/trunk/ \
+ svn://.../pkg-perl/libfile-touch-perl/tags/tag_we_forgot
+
+=head1 6. Upstream upgrade
+
+TODO
+
+=head1 7. Hints and tricks
+
+=over 4
+
+=item How to have svn-buildpackage not ask for a password so often
+
+One of the annoying things about svn-buildpackage is that when you
+checkout a package using svn+ssh, it will ask your password pretty
+often when building, say 25 times. This tends to be annoying by the
+second time you type in your password. This will save you some
+password typing:
+
+ ssh-copy-id [-i] user@svn.debian.org
+
+Beware that the Alioth maintainers delete the authorized_keys
+automatically after an hour or so.
+
+=item How to not build directly under trunk/../build-area
+
+Often, you'll check out an entire package with trunk, branches and
+tags. Or, you'll inject a package using svn-inject and want to build
+the package later. The standard location for svn-buildpackage will be
+../build-area/. However, if working from trunk/, this places the build
+area inside the svn checkout directory, polluting the checkout.
+
+The solution is to put one line in a file called
+trunk/.svn/deb-layout. This file is automatically created by
+svn-buildpackage but we can place our defaults there before it starts.
+The line reads:
+
+ buildArea=/usr/src/debian/perl/pkg-perl/build-area
+
+=back
+
+=head1 LICENSE
+
+Copyright (c) 2004 Allard Hoeve. All rights reserved. This program is
+free software; you may redistribute it and/or modify it under the same
+terms as Perl itself
+
+Perl is distributed under your choice of the GNU General Public
+License or the Artistic License. On Debian GNU/Linux systems, the
+complete text of the GNU General Public License can be found in
+`/usr/share/common-licenses/GPL' and the Artistic Licence in
+`/usr/share/common-licenses/Artistic'.