diff --git a/.compat-libcap1.metadata b/.compat-libcap1.metadata
new file mode 100644
index 0000000..2edd786
--- /dev/null
+++ b/.compat-libcap1.metadata
@@ -0,0 +1 @@
+95e86a451df60db26152f753ed5f880d42a41884 SOURCES/libcap-1.10.tar.gz
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..54fca76
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+SOURCES/libcap-1.10.tar.gz
diff --git a/SOURCES/capfaq-0.2.txt b/SOURCES/capfaq-0.2.txt
new file mode 100644
index 0000000..e3e272b
--- /dev/null
+++ b/SOURCES/capfaq-0.2.txt
@@ -0,0 +1,264 @@
+This is the Linux kernel capabilities FAQ
+
+Its history, to the extent that I am able to reconstruct it is that
+v2.0 was posted to the Linux kernel list on 1999/04/02 by Boris
+Tobotras. Thanks to Denis Ducamp for forwarding me a copy.
+
+Cheers
+
+Andrew
+
+Linux Capabilities FAQ 0.2
+==========================
+
+1) What is a capability?
+
+The name "capabilities" as used in the Linux kernel can be confusing.
+First there are Capabilities as defined in computer science. A
+capability is a token used by a process to prove that it is allowed to
+do an operation on an object. The capability identifies the object
+and the operations allowed on that object. A file descriptor is a
+capability. You create the file descriptor with the "open" call and
+request read or write permissions. Later, when doing a read or write
+operation, the kernel uses the file descriptor as an index into a
+data structure that indicates what operations are allowed. This is an
+efficient way to check permissions. The necessary data structures are
+created once during the "open" call. Later read and write calls only
+have to do a table lookup. Operations on capabilities include copying
+capabilities, transferring capabilities between processes, modifying a
+capability, and revoking a capability. Modifying a capability can be
+something like taking a read-write filedescriptor and making it
+read-only. A capability often has a notion of an "owner" which is
+able to invalidate all copies and derived versions of a capability.
+Entire OSes are based on this "capability" model, with varying degrees
+of purity. There are other ways of implementing capabilities than the
+file descriptor model - traditionally special hardware has been used,
+but modern systems also use the memory management unit of the CPU.
+
+Then there is something quite different called "POSIX capabilities"
+which is what Linux uses. These capabilities are a partitioning of
+the all powerful root privilege into a set of distinct privileges (but
+look at securelevel emulation to find out that this isn't necessary
+the whole truth). Users familiar with VMS or "Trusted" versions of
+other UNIX variants will know this under the name "privileges". The
+name "capabilities" comes from the now defunct POSIX draft 1003.1e
+which used this name.
+
+2) So what is a "POSIX capability"?
+
+A process has three sets of bitmaps called the inheritable(I),
+permitted(P), and effective(E) capabilities. Each capability is
+implemented as a bit in each of these bitmaps which is either set or
+unset. When a process tries to do a privileged operation, the
+operating system will check the appropriate bit in the effective set
+of the process (instead of checking whether the effective uid of the
+process i 0 as is normally done). For example, when a process tries
+to set the clock, the Linux kernel will check that the process has the
+CAP_SYS_TIME bit (which is currently bit 25) set in its effective set.
+
+The permitted set of the process indicates the capabilities the
+process can use. The process can have capabilities set in the
+permitted set that are not in the effective set. This indicates that
+the process has temporarily disabled this capability. A process is
+allowed to set a bit in its effective set only if it is available in
+the permitted set. The distinction between effective and permitted
+exists so that processes can "bracket" operations that need privilege.
+
+The inheritable capabilities are the capabilities of the current
+process that should be inherited by a program executed by the current
+process. The permitted set of a process is masked against the
+inheritable set during exec(). Nothing special happens during fork()
+or clone(). Child processes and threads are given an exact copy of
+the capabilities of the parent process.
+
+3) What about other entities in the system? Users, Groups, Files?
+
+Files have capabilities. Conceptually they have the same three
+bitmaps that processes have, but to avoid confusion we call them by
+other names. Only executable files have capabilities, libraries don't
+have capabilities (yet). The three sets are called the allowed set,
+the forced set, and the effective set.
+
+The allowed set indicates what capabilities the executable is allowed
+to receive from an execing process. This means that during exec(),
+the capabilities of the old process are first masked against a set
+which indicates what the process gives away (the inheritable set of
+the process), and then they are masked against a set which indicates
+what capabilities the new process image is allowed to receive (the
+allowed set of the executable).
+
+The forced set is a set of capabilities created out of thin air and
+given to the process after execing the executable. The forced set is
+similar in nature to the setuid feature. In fact, the setuid bit from
+the filesystem is "read" as a full forced set by the kernel.
+
+The effective set indicates which bits in the permitted set of the new
+process should be transferred to the effective set of the new process.
+The effective set is best thought of as a "capability aware" set. It
+should consist of only 1s if the executable is capability-dumb, or
+only 0s if the executable is capability-smart. Since the effective
+set consists of only 0s or only 1s, the filesystem can implement this
+set using a single bit.
+
+NOTE: Filesystem support for capabilities is not part of Linux 2.2.
+
+Users and Groups don't have associated capabilities from the kernel's
+point of view, but it is entirely reasonable to associate users or
+groups with capabilities. By letting the "login" program set some
+capabilities it is possible to make role users such as a backup user
+that will have the CAP_DAC_READ_SEARCH capability and be able to do
+backups. This could also be implemented as a PAM module, but nobody
+has implemented one yet.
+
+4) What capabilities exist?
+
+The capabilities available in Linux are listed and documented in the
+file /usr/src/linux/include/linux/capability.h.
+
+5) Are Linux capabilities hierarchical?
+
+No, you cannot make a "subcapability" out of a Linux capability as in
+capability-based OSes.
+
+6) How can I use capabilities to make sure Mr. Evil Luser (eluser)
+can't exploit my "suid" programs?
+
+This is the general outline of how this works given filesystem
+capability support exists. First, you have a PAM module that sets the
+inheritable capabilities of the login-shell of eluser. Then for all
+"suid" programs on the system, you decide what capabilities they need
+and set the _allowed_ set of the executable to that set of
+capabilities. The capability rules
+
+ new permitted = forced | (allowed & inheritable)
+
+means that you should be careful about setting forced capabilities on
+executables. In a few cases, this can be useful though. For example
+the login program needs to set the inheritable set of the new user and
+therefore needs an almost full permitted set. So if you want eluser
+to be able to run login and log in as a different user, you will have
+to set some forced bits on that executable.
+
+7) What about passing capabilities between processes?
+
+Currently this is done by the system call "setcap" which can set the
+capabilities of another process. This requires the CAP_SETPCAP
+capability which you really only want to grant a _few_ processes.
+CAP_SETPCAP was originally intended as a workaround to be able to
+implement filesystem support for capabilities using a daemon outside
+the kernel.
+
+There has been discussions about implementing socket-level capability
+passing. This means that you can pass a capability over a socket. No
+support for this exists in the official kernel yet.
+
+8) I see securelevel has been removed from 2.2 and are superceeded by
+capabilities. How do I emulate securelevel using capabilities?
+
+The setcap system call can remove a capability from _all_ processes on
+the system in one atomic operation. The setcap utility from the
+libcap distribution will do this for you. The utility requires the
+CAP_SETPCAP privilege to do this. The CAP_SETPCAP capability is not
+enabled by default.
+
+libcap is available from
+ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/
+
+9) I noticed that the capability.h file lacks some capabilities that
+are needed to fully emulate 2.0 securelevel. Is there a patch for
+this?
+
+Actually yes - funny you should ask :-). The problem with 2.0
+securelevel is that they for example stop root from accessing block
+devices. At the same time they restrict the use of iopl. These two
+changes are fundamentally different. Blocking access to block devices
+means restricting something that usually isn't restricted.
+Restricting access to the use of iopl on the other hand means
+restricting (blocking) access to something that is already blocked.
+Emulating the parts of 2.0 securelevel that restricts things that are
+normally not restricted means that the capabilites in the kernel has
+to have a set of capabilities that are usually _on_ for a normal
+process (note that this breaks the explanation that capabilities are a
+partitioning of the root privileges). There is an experimental patch at
+
+ftp://ftp.guardian.no/pub/free/linux/capabilities/patch-cap-exp-1
+
+which implements a set of capabilities with the "CAP_USER" prefix:
+
+cap_user_sock - allowed to use socket()
+cap_user_dev - allowed to open char/block devices
+cap_user_fifo - allowed to use pipes
+
+These should be enough to emulate 2.0 securelevel (tell me if we need
+something more).
+
+10) Seems I need a CAP_SETPCAP capability that I don't have to make use
+of capabilities. How do I enable this capability?
+
+Change the definition of CAP_INIT_EFF_SET and CAP_INIT_INH_SET to the
+following in include/linux/capability.h:
+
+#define CAP_INIT_EFF_SET { ~0 }
+#define CAP_INIT_INH_SET { ~0 }
+
+This will start init with a full capability set and not with
+CAP_SETPCAP removed.
+
+11) How do I start a process with a limited set of capabilities?
+
+Get the libcap library and use the execcap utility. The following
+example starts the update daemon with only the CAP_SYS_ADMIN
+capability.
+
+execcap 'cap_sys_admin=eip' update
+
+12) How do I start a process with a limited set of capabilities under
+another uid?
+
+Use the sucap utility which changes uid from root without loosing any
+capabilities. Normally all capabilities are cleared when changing uid
+from root. The sucap utility requires the CAP_SETPCAP capability.
+The following example starts updated under uid updated and gid updated
+with CAP_SYS_ADMIN raised in the Effective set.
+
+sucap updated updated execcap 'cap_sys_admin=eip' update
+
+[ Sucap is currently available from
+ftp://ftp.guardian.no/pub/free/linux/capabilities/sucap.c. Put it in
+the progs directory of libcap to compile.]
+
+13) What are the "capability rules"
+
+The capability rules are the rules used to set the capabilities of the
+new process image after an exec. They work like this:
+
+ pI' = pI
+ (***) pP' = fP | (fI & pI)
+ pE' = pP' & fE [NB. fE is 0 or ~0]
+
+ I=Inheritable, P=Permitted, E=Effective // p=process, f=file
+ ' indicates post-exec().
+
+Now to make sense of the equations think of fP as the Forced set of
+the executable, and fI as the Allowed set of the executable. Notice
+how the Inheritable set isn't touched at all during exec().
+
+14) What are the laws for setting capability bits in the Inheritable,
+Permitted, and Effective sets?
+
+Bits can be transferred from Permitted to either Effective or
+Inheritable set.
+
+Bits can be removed from all sets.
+
+15) Where is the standard on which the Linux capabilities are based?
+
+There used to be a POSIX draft called POSIX.6 and later POSIX 1003.1e.
+However after the committee had spent over 10 years, POSIX decided
+that enough is enough and dropped the draft. There will therefore not
+be a POSIX standard covering security anytime soon. This may lead to
+that the POSIX draft is available for free, however.
+
+--
+ Best regards, -- Boris.
+
diff --git a/SOURCES/libcap-1.10-alpha.patch b/SOURCES/libcap-1.10-alpha.patch
new file mode 100644
index 0000000..d0cadf9
--- /dev/null
+++ b/SOURCES/libcap-1.10-alpha.patch
@@ -0,0 +1,11 @@
+--- libcap-1.10/libcap/_makenames.c.foo Fri Nov 9 16:38:45 2001
++++ libcap-1.10/libcap/_makenames.c Fri Nov 9 16:39:30 2001
+@@ -9,7 +9,7 @@
+
+ #include <stdio.h>
+ #include <stdlib.h>
+-#include <linux/capability.h>
++#include "include/sys/capability.h"
+
+ /*
+ * #include 'sed' generated array
diff --git a/SOURCES/libcap-1.10-ia64.patch b/SOURCES/libcap-1.10-ia64.patch
new file mode 100644
index 0000000..bc572f5
--- /dev/null
+++ b/SOURCES/libcap-1.10-ia64.patch
@@ -0,0 +1,34 @@
+diff -up libcap-1.10/libcap/cap_sys.c.ia64 libcap-1.10/libcap/cap_sys.c
+--- libcap-1.10/libcap/cap_sys.c.ia64 1999-04-18 00:16:31.000000000 +0200
++++ libcap-1.10/libcap/cap_sys.c 2012-10-17 22:34:16.059369216 +0200
+@@ -11,14 +11,6 @@
+ #define __LIBRARY__
+ #include <linux/unistd.h>
+
+-_syscall2(int, capget,
+- cap_user_header_t, header,
+- cap_user_data_t, data)
+-
+-_syscall2(int, capset,
+- cap_user_header_t, header,
+- const cap_user_data_t, data)
+-
+ /*
+ * $Log: cap_sys.c,v $
+ * Revision 1.1.1.1 1999/04/17 22:16:31 morgan
+diff -up libcap-1.10/Make.Rules.ia64 libcap-1.10/Make.Rules
+--- libcap-1.10/Make.Rules.ia64 1999-11-18 07:06:02.000000000 +0100
++++ libcap-1.10/Make.Rules 2012-10-17 22:32:23.477360230 +0200
+@@ -44,10 +44,10 @@ MINOR=10
+ CC=gcc
+ COPTFLAGS=-O2
+ DEBUG=-g #-DDEBUG
+-WARNINGS=-ansi -D_POSIX_SOURCE -Wall -Wwrite-strings \
++WARNINGS=-D_POSIX_SOURCE -Wall -Wwrite-strings \
+ -Wpointer-arith -Wcast-qual -Wcast-align \
+ -Wtraditional -Wstrict-prototypes -Wmissing-prototypes \
+- -Wnested-externs -Winline -Wshadow -pedantic
++ -Wnested-externs -Winline -Wshadow
+ LD=ld
+ LDFLAGS=-s #-g
+
diff --git a/SOURCES/libcap-1.10-shared.patch b/SOURCES/libcap-1.10-shared.patch
new file mode 100644
index 0000000..54e5496
--- /dev/null
+++ b/SOURCES/libcap-1.10-shared.patch
@@ -0,0 +1,17 @@
+--- libcap-1.11/libcap/Makefile.shared 1999-04-17 18:16:31.000000000 -0400
++++ libcap-1.11/libcap/Makefile 2002-07-19 06:24:23.000000000 -0400
+@@ -56,12 +56,12 @@ cap_names.sed: Makefile /usr/include/lin
+ # @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define CAP_\([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < /usr/include/linux/capability.h | fgrep -v 0x > cap_names.sed
+
+ $(MINLIBNAME): $(OBJS)
+- $(LD) -soname $(MAJLIBNAME) -x -shared -o $@ $(OBJS)
++ $(CC) -Wl,-soname,$(MAJLIBNAME) -Wl,-x -shared -o $@ $(OBJS)
+ ln -sf $(MINLIBNAME) $(MAJLIBNAME)
+ ln -sf $(MAJLIBNAME) $(LIBNAME)
+
+ %.o: %.c $(INCLS)
+- $(CC) $(CFLAGS) -c $< -o $@
++ $(CC) $(CFLAGS) -fpic -c $< -o $@
+
+ install: all
+ mkdir -p -m 0755 $(INCDIR)/sys
diff --git a/SOURCES/libcap-1.10-types.patch b/SOURCES/libcap-1.10-types.patch
new file mode 100644
index 0000000..97e4118
--- /dev/null
+++ b/SOURCES/libcap-1.10-types.patch
@@ -0,0 +1,10 @@
+--- libcap-1.10/libcap/include/sys/capability.h 2010-08-17 20:55:28.000000000 +0200
++++ libcap-1.10_/libcap/include/sys/capability.h 2010-08-17 20:54:41.000000000 +0200
+@@ -21,6 +21,7 @@
+ */
+
+ #include <sys/types.h>
++#include <linux/types.h>
+ #include <stdint.h>
+
+ /*
diff --git a/SOURCES/libcap-1.10-useCFLAGSwithCC.patch b/SOURCES/libcap-1.10-useCFLAGSwithCC.patch
new file mode 100644
index 0000000..4fa83ad
--- /dev/null
+++ b/SOURCES/libcap-1.10-useCFLAGSwithCC.patch
@@ -0,0 +1,22 @@
+--- libcap-1.10/libcap/Makefile.BAD 2006-07-13 20:42:35.000000000 -0400
++++ libcap-1.10/libcap/Makefile 2006-07-13 20:42:53.000000000 -0400
+@@ -56,7 +56,7 @@
+ # @sed -ne '/^#define[ \t]CAP[_A-Z]\+[ \t]\+[0-9]\+/{s/^#define CAP_\([^ \t]*\)[ \t]*\([^ \t]*\)/ \{ \2, \"\1\" \},/;y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/;p;}' < /usr/include/linux/capability.h | fgrep -v 0x > cap_names.sed
+
+ $(MINLIBNAME): $(OBJS)
+- $(CC) -Wl,-soname,$(MAJLIBNAME) -Wl,-x -shared -o $@ $(OBJS)
++ $(CC) $(COPTFLAG) -Wl,-soname,$(MAJLIBNAME) -Wl,-x -shared -o $@ $(OBJS)
+ ln -sf $(MINLIBNAME) $(MAJLIBNAME)
+ ln -sf $(MAJLIBNAME) $(LIBNAME)
+
+--- libcap-1.10/progs/Makefile.BAD 2006-07-13 20:48:44.000000000 -0400
++++ libcap-1.10/progs/Makefile 2006-07-13 20:48:54.000000000 -0400
+@@ -36,7 +36,7 @@
+ all: $(PROGS)
+
+ $(PROGS): %: %.o
+- $(CC) $(LDFLAGS) -o $@ $< $(LIBS)
++ $(CC) $(COPTFLAG) $(LDFLAGS) -o $@ $< $(LIBS)
+
+ %.o: %.c $(INCS)
+ $(CC) $(CFLAGS) -c $< -o $@
diff --git a/SOURCES/libcap-1.10-userland.patch b/SOURCES/libcap-1.10-userland.patch
new file mode 100644
index 0000000..0cd608f
--- /dev/null
+++ b/SOURCES/libcap-1.10-userland.patch
@@ -0,0 +1,19 @@
+--- libcap-1.10/libcap/include/sys/capability.h.foo Fri Nov 9 16:26:25 2001
++++ libcap-1.10/libcap/include/sys/capability.h Fri Nov 9 16:28:47 2001
+@@ -21,6 +21,16 @@
+ */
+
+ #include <sys/types.h>
++#include <stdint.h>
++
++/*
++ * Make sure we can be included from userland by preventing
++ * capability.h from including other kernel headers
++ */
++#define _LINUX_TYPES_H
++#define _LINUX_FS_H
++typedef unsigned int __u32;
++
+ #include <linux/capability.h>
+
+ /*
diff --git a/SPECS/compat-libcap1.spec b/SPECS/compat-libcap1.spec
new file mode 100644
index 0000000..2112f43
--- /dev/null
+++ b/SPECS/compat-libcap1.spec
@@ -0,0 +1,191 @@
+Name: compat-libcap1
+Version: 1.10
+Release: 7%{?dist}
+Summary: Library for getting and setting POSIX.1e capabilities
+Source: ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/libcap-1.10.tar.gz
+Source1: http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt
+License: BSD-like and LGPL
+Patch: libcap-1.10-ia64.patch
+Patch1: libcap-1.10-userland.patch
+Patch2: libcap-1.10-shared.patch
+Patch3: libcap-1.10-alpha.patch
+Patch4: libcap-1.10-useCFLAGSwithCC.patch
+Patch5: libcap-1.10-types.patch
+Group: System Environment/Libraries
+BuildRoot: %{_tmppath}/%{name}-%{version}-root
+
+%description
+libcap is a library for getting and setting POSIX.1e (formerly POSIX 6)
+draft 15 capabilities.
+
+%prep
+%setup -q -n libcap-1.10
+# FIXME: Is this really required still?
+%patch -p1 -b .ia64
+%ifarch alpha
+# FIXME: Is this really required still?
+%patch3 -p1 -b .alpha
+%endif
+%patch1 -p1 -b .userland
+%patch2 -p1 -b .shared
+%patch4 -p1
+%patch5 -p1
+
+%build
+make PREFIX=%{_prefix} LIBDIR=%{_libdir} CFLAGS="%{optflags} -I$PWD/libcap/include/"
+
+%install
+rm -rf ${RPM_BUILD_ROOT}
+make install FAKEROOT=${RPM_BUILD_ROOT} \
+ LIBDIR=${RPM_BUILD_ROOT}/%{_libdir} \
+ SBINDIR=${RPM_BUILD_ROOT}/%{_sbindir} \
+ INCDIR=${RPM_BUILD_ROOT}/%{_includedir} \
+ MANDIR=${RPM_BUILD_ROOT}/%{_mandir}/ \
+ COPTFLAG="$RPM_OPT_FLAGS"
+mkdir -p ${RPM_BUILD_ROOT}/%{_mandir}/man{2,3,8}
+rm -f doc/cap_set_fd* doc/cap_set_file*
+#mv -f doc/*.2 ${RPM_BUILD_ROOT}/%{_mandir}/man2/
+#mv -f doc/*.3 ${RPM_BUILD_ROOT}/%{_mandir}/man3/
+cp %{SOURCE1} doc/
+
+chmod +x ${RPM_BUILD_ROOT}/%{_libdir}/*.so.*
+rm -rf ${RPM_BUILD_ROOT}/%{_sbindir}/
+rm -rf ${RPM_BUILD_ROOT}/%{_includedir}/
+rm -rf ${RPM_BUILD_ROOT}/%{_libdir}/*.so
+rm -rf ${RPM_BUILD_ROOT}/%{_mandir}/man2/*
+rm -rf ${RPM_BUILD_ROOT}/%{_mandir}/man3/*
+
+%post -p /sbin/ldconfig
+%postun -p /sbin/ldconfig
+
+%files
+%defattr(-,root,root)
+/%{_libdir}/*.so.*
+%doc doc/capability.notes doc/capfaq-0.2.txt
+
+%clean
+rm -rf ${RPM_BUILD_ROOT}
+
+%changelog
+* Fri Mar 07 2014 Karsten Hopp <karsten@redhat.com> 1.10-7
+- move libraries to /usr/lib*
+
+* Fri Mar 07 2014 Karsten Hopp <karsten@redhat.com> 1.10-6
+- use optflags, ensures that -fstack-protector-strong flag is used
+- Resolves: rhbz 1070799
+
+* Fri Jan 24 2014 Daniel Mach <dmach@redhat.com> - 1.10-5
+- Mass rebuild 2014-01-24
+
+* Fri Dec 27 2013 Daniel Mach <dmach@redhat.com> - 1.10-4
+- Mass rebuild 2013-12-27
+
+* Wed Nov 21 2012 Karsten Hopp <karsten@redhat.com> 1.10-3
+- fix source URLs
+
+* Wed Oct 17 2012 Karsten Hopp <karsten@redhat.com> 1.10-2
+- update patch
+
+* Tue Aug 24 2010 Karsten Hopp <karsten@redhat.com> 1.10-1
+- package as compat-libcap1
+
+* Tue Aug 17 2010 Karsten Hopp <karsten@redhat.com> 1.10-26.kh
+- include linux/types.h in capability.h
+
+* Tue Nov 14 2006 Karsten Hopp <karsten@redhat.com> 1.10-26
+- remove obsolete manpages (#215402)
+
+* Wed Jul 19 2006 Karsten Hopp <karsten@redhat.de> 1.10-25
+- add patch to support COPTFLAG (#199365)
+
+* Wed Jul 12 2006 Jesse Keating <jkeating@redhat.com> - 1.10-24.2.1
+- rebuild
+
+* Fri Feb 10 2006 Jesse Keating <jkeating@redhat.com> - 1.10-24.2
+- bump again for double-long bug on ppc(64)
+
+* Tue Feb 07 2006 Jesse Keating <jkeating@redhat.com> - 1.10-24.1
+- rebuilt for new gcc4.1 snapshot and glibc changes
+
+* Mon Dec 19 2005 Karsten Hopp <karsten@redhat.de> 1.10-24
+- added development manpages
+- as there are no manpages for the executables available, added at least
+ a FAQ (#172324)
+
+* Fri Dec 09 2005 Jesse Keating <jkeating@redhat.com>
+- rebuilt
+
+* Mon Oct 31 2005 Steve Grubb <sgrubb@redhat.com> 1.10-23
+- rebuild to pick up audit capabilities
+
+* Wed Mar 02 2005 Karsten Hopp <karsten@redhat.de> 1.10-22
+- build with gcc-4
+
+* Wed Feb 09 2005 Karsten Hopp <karsten@redhat.de> 1.10-21
+- rebuilt
+
+* Tue Aug 31 2004 Phil Knirsch <pknirsch@redhat.com> 1.10-20
+- Fix wrong typedef in userland patch (#98801)
+
+* Tue Jun 15 2004 Elliot Lee <sopwith@redhat.com>
+- rebuilt
+
+* Tue Mar 02 2004 Elliot Lee <sopwith@redhat.com>
+- rebuilt
+
+* Fri Feb 13 2004 Elliot Lee <sopwith@redhat.com>
+- rebuilt
+
+* Tue Jan 27 2004 Karsten Hopp <karsten@redhat.de> 1.10-17
+- use _manpath
+
+* Wed Jun 04 2003 Elliot Lee <sopwith@redhat.com>
+- rebuilt
+
+* Wed Jan 22 2003 Tim Powers <timp@redhat.com>
+- rebuilt
+
+* Sat Jan 4 2003 Jeff Johnson <jbj@redhat.com> 1.10-14
+- set execute bits on library so that requires are generated.
+
+* Thu Nov 21 2002 Mike A. Harris <mharris@redhat.com> 1.10-13
+- Removed %%name macro sillyness from package Summary, description text, etc.
+- Removed archaic Prefix: tag
+- lib64 fixes everywhere to use _lib, _libdir, etc
+- Removed deletion of RPM_BUILD_DIR from %%clean section
+- Added -q flag to setup macro
+- Severely cleaned up spec file, and removed usage of perl
+
+* Fri Jul 19 2002 Jakub Jelinek <jakub@redhat.com> 1.10-12
+- CFLAGS was using COPTFLAG variable, not COPTFLAGS
+- build with -fpic
+- apply the IA-64 patch everywhere, use capget/capset from glibc,
+ not directly as _syscall (as it is broken on IA-32 with -fpic)
+- reenable alpha
+
+* Fri Jun 21 2002 Tim Powers <timp@redhat.com>
+- automated rebuild
+
+* Wed May 29 2002 Bernhard Rosenkraenzer <bero@redhat.com> 1.10-10
+- Exclude alpha for now, apparent gcc bug.
+
+* Fri Nov 9 2001 Bernhard Rosenkraenzer <bero@redhat.com> 1.10-6
+- Fix sys/capabilities.h header (#55727)
+- Move to /lib, some applications seem to be using this rather early
+ (#55733)
+
+* Mon Jul 16 2001 Trond Eivind Glomsr�d <teg@redhat.com>
+- Add post,postun scripts
+
+* Tue Jul 10 2001 Jakub Jelinek <jakub@redhat.com>
+- don't build libcap.so.1 with ld -shared, but gcc -shared
+
+* Wed Jun 20 2001 Trond Eivind Glomsr�d <teg@redhat.com>
+- Rebuild - it was missing for alpha
+
+* Wed Jun 06 2001 Florian La Roche <Florian.LaRoche@redhat.de>
+- add s390/s390x support
+
+* Thu May 17 2001 Bernhard Rosenkraenzer <bero@redhat.com> 1.10-1
+- initial RPM
+- fix build on ia64