From 0b6b506536c1ff50f1531d26be2fccfe86c74335 Mon Sep 17 00:00:00 2001
From: zuntum <zuntum>
Date: Thu, 1 Nov 2001 00:57:41 +0000
Subject: Move pkg/ files into package's toplevel directory

---
 misc/buffer/DESCR     | 27 +++++++++++++++++++++++++++
 misc/buffer/PLIST     |  3 +++
 misc/buffer/pkg/DESCR | 27 ---------------------------
 misc/buffer/pkg/PLIST |  3 ---
 4 files changed, 30 insertions(+), 30 deletions(-)
 create mode 100644 misc/buffer/DESCR
 create mode 100644 misc/buffer/PLIST
 delete mode 100644 misc/buffer/pkg/DESCR
 delete mode 100644 misc/buffer/pkg/PLIST

(limited to 'misc/buffer')

diff --git a/misc/buffer/DESCR b/misc/buffer/DESCR
new file mode 100644
index 00000000000..70a1cccc772
--- /dev/null
+++ b/misc/buffer/DESCR
@@ -0,0 +1,27 @@
+This is a program designed to speed up writing tapes on remote tape
+drives.  Requirements are shared memory and locks which normally
+means that these are supported in your kernel.
+
+[for Free/NetBSD, this means you MUST have a kernel with 
+ options SYSVSHM
+ compiled in - markm]
+
+Buffer has been tested under SunOS 4.0.*, SunOS 4.1.*, Solarix, HP-UX 7.0,
+and Gould UTX 2.1A (sv universe).
+
+The program splits itself into two processes.  The first process reads
+(and reblocks) from stdin into a shared memory buffer.  The second
+writes from the shared memory buffer to stdout.  Doing it this way
+means that the writing side effectly sits in a tight write loop and
+doesn't have to wait for input.  Similarly for the input side.  It is
+this waiting that slows down other reblocking processes, like dd.
+
+I run an archive and need to write large chunks out to tape regularly
+with an ethernet in the way.  Using 'buffer' in a command like:
+
+	tar cvf - stuff | rsh somebox "buffer > /dev/rst8"
+
+is a factor of 5 faster than the best alternative, gnu tar with its
+remote tape option:
+
+	tar cvf somebox:/dev/rst8 stuff
diff --git a/misc/buffer/PLIST b/misc/buffer/PLIST
new file mode 100644
index 00000000000..cdcdf82578b
--- /dev/null
+++ b/misc/buffer/PLIST
@@ -0,0 +1,3 @@
+@comment $NetBSD: PLIST,v 1.1 2001/11/01 01:27:37 zuntum Exp $
+bin/buffer
+man/man1/buffer.1.gz
diff --git a/misc/buffer/pkg/DESCR b/misc/buffer/pkg/DESCR
deleted file mode 100644
index 70a1cccc772..00000000000
--- a/misc/buffer/pkg/DESCR
+++ /dev/null
@@ -1,27 +0,0 @@
-This is a program designed to speed up writing tapes on remote tape
-drives.  Requirements are shared memory and locks which normally
-means that these are supported in your kernel.
-
-[for Free/NetBSD, this means you MUST have a kernel with 
- options SYSVSHM
- compiled in - markm]
-
-Buffer has been tested under SunOS 4.0.*, SunOS 4.1.*, Solarix, HP-UX 7.0,
-and Gould UTX 2.1A (sv universe).
-
-The program splits itself into two processes.  The first process reads
-(and reblocks) from stdin into a shared memory buffer.  The second
-writes from the shared memory buffer to stdout.  Doing it this way
-means that the writing side effectly sits in a tight write loop and
-doesn't have to wait for input.  Similarly for the input side.  It is
-this waiting that slows down other reblocking processes, like dd.
-
-I run an archive and need to write large chunks out to tape regularly
-with an ethernet in the way.  Using 'buffer' in a command like:
-
-	tar cvf - stuff | rsh somebox "buffer > /dev/rst8"
-
-is a factor of 5 faster than the best alternative, gnu tar with its
-remote tape option:
-
-	tar cvf somebox:/dev/rst8 stuff
diff --git a/misc/buffer/pkg/PLIST b/misc/buffer/pkg/PLIST
deleted file mode 100644
index ba4443057b1..00000000000
--- a/misc/buffer/pkg/PLIST
+++ /dev/null
@@ -1,3 +0,0 @@
-@comment $NetBSD: PLIST,v 1.4 1998/03/10 14:42:22 frueauf Exp $
-bin/buffer
-man/man1/buffer.1.gz
-- 
cgit v1.2.3