[Pkg-wmaker-commits] [wmaker] 01/01: Remove out of date file README.build.

[Doug Torrance]

This is an automated email from the git hooks/post-receive script.

dtorrance-guest pushed a commit to branch master
in repository wmaker.

commit 963b3943f5e115ed038844d026a7df0afbd25355
Author: Doug Torrance <dtorrance at piedmont.edu>
Date:   Tue Feb 16 21:47:16 2016 -0500

    Remove out of date file README.build.
---
 debian/README.build | 78 -----------------------------------------------------
 1 file changed, 78 deletions(-)

diff --git a/debian/README.build b/debian/README.build
deleted file mode 100644
index be5b8f2..0000000
--- a/debian/README.build
+++ /dev/null
@@ -1,78 +0,0 @@
-Building Window Maker for Debian
---------------------------------
-
-* The patches
-
-  debian/rules scans debian/patches/ for files named *.diff and these
-  are sorted _alphabetically_ before being applied.
-
-  You can apply these patches by calling
-
-  	$ debian/rules patch-wmaker-stamp
-
-  and remove them with
-
-  	$ debian/rules unpatch-wmaker
-
-  Why are some patches in debian/patches and others are stored in the
-  debian .diff?
-  
-	  For starters I (still) dislike the idea of doing:
-
-		$ dpkg -x package.dsc
-
-	  and being left with something that is not the source from
-	  which the package is built.  It makes NMUs harder for both the
-	  NMUer and the maintainer, mostly because people tend to get it
-	  wrong (since it's undocumented).  I use CVS for (almost all
-	  of) my packages, and I like to be able to take a look at the
-	  source used to build certain release of a package _without_
-	  having to check out that release.  On the other hand, I try to
-	  send patches upstream, and over the years I've learned that
-	  Debian's source package format is really not the best thing to
-	  use in this context.  Merging between debian's source and
-	  upstream's (after accepting patches) is messy.
-
-	  The system used by this package is a compromise between these
-	  two things: "most" of the patches are applied directly by just
-	  unpacking the Debian sources, and some are left out.  The
-	  things that are left out (those stored in debian/patches) are
-	  in general things that should go upstream.  Things that aren't
-	  really Debian specific.  Security fixes, patches submitted
-	  upstream by other people, that kind of thing.  This keeps the
-	  patches nicely separated, makes it easy to send the upstream,
-	  to take them out and to update them if that becomes necessary.
-	  In general, if it's Debian specific, patch the sources
-	  directly.  If it should go upstream, put it in debian/patches.
-
-  The easiest way to generate patches is to use CVS.  Patches coming out
-  of 'cvs diff -u whaterver/you.modded' will just work if you put them
-  in debian/patches.  If you can't use CVS for whatever reason, just:
-
-  $ diff -u wmaker.orig wmaker > your.patch
-
-  will do the right thing.
-
-* Building options
-
-  The following make variables are used to pass options to the configure
-  script:
-
-	XLOCALE  := --disable-locale
-	MODELOCK := --enable-modelock
-
-	XINERAMA := --enable-xinerama
-
-	(*) These are not used by default
-
-  Since these are make variables, you can do something like:
-
-  	$ SOUND=--disable-sound debian/rules build
-
-  If you want to build a debugging version, this will do it:
-
-  $ export DEB_BUILD_OPTIONS=nostrip,debug,noopt
-  $ fakeroot debian/rules binary
-
--- 
-vim: tw=72 ft=text

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-wmaker/wmaker.git