* Strongly buildlinkify.

* Use qt2-designer-kde for a uic that understands KDE2 widgets.
* Fix problem noted by Marcello Balduccini <marcello.balduccini@ttu.edu>
  in how kpgp handles pipes with child processes -- prevents kpgp from
  remaining stuck while waiting for the child pgp process to terminate.

4 files changed, 81 insertions, 13 deletions

diff --git a/net/kdenetwork2/Makefile b/net/kdenetwork2/Makefile
index 023edc46c84..e495adf9e90 100644
--- a/net/kdenetwork2/Makefile
+++ b/net/kdenetwork2/Makefile
@@ -1,16 +1,19 @@
-# $NetBSD: Makefile,v 1.5 2001/10/15 22:46:15 skrll Exp $
-#
+# $NetBSD: Makefile,v 1.6 2001/11/13 21:25:54 jlam Exp $
 
 DISTNAME=	kdenetwork-2.2.1
-CATEGORIES=	net kde
-.include "../../x11/kde2/Makefile.part1"
+CATEGORIES=	net
 COMMENT=	Network modules for the KDE integrated X11 desktop
 
-DEPENDS=	gdbm>=1.7.3:../../databases/gdbm
-DEPENDS+=	uulib>=0.5.13:../../converters/uulib
-DEPENDS+=	ptl>=2.1.7:../../devel/ptl2
-DEPENDS+=	kdebase>=2.2.1:../../x11/kdebase2
+.include "../../x11/kde2/Makefile.kde2"
 
-.include "../../x11/kde2/Makefile.part2"
+BUILD_DEPENDS+=	qt2-designer-kde>=2.3.1nb1:../../x11/qt2-designer-kde
 
+USE_BUILDLINK_ONLY=	YES
+
+.include "../../converters/uulib/buildlink.mk"
+.include "../../databases/gdbm/buildlink.mk"
+.include "../../devel/ptl2/buildlink.mk"
+.include "../../x11/kde2/buildlink.mk"
+.include "../../x11/kdebase2/buildlink.mk"
+.include "../../mk/x11.buildlink.mk"
 .include "../../mk/bsd.pkg.mk"
diff --git a/net/kdenetwork2/distinfo b/net/kdenetwork2/distinfo
index 1d49f7db697..78b73f41a1e 100644
--- a/net/kdenetwork2/distinfo
+++ b/net/kdenetwork2/distinfo
@@ -1,7 +1,8 @@
-$NetBSD: distinfo,v 1.4 2001/10/22 11:03:50 skrll Exp $
+$NetBSD: distinfo,v 1.5 2001/11/13 21:25:54 jlam Exp $
 
 SHA1 (kdenetwork-2.2.1.tar.bz2) = 552de572226c85f4a20772b3cffe9ac58ef08148
 Size (kdenetwork-2.2.1.tar.bz2) = 3150618 bytes
-SHA1 (patch-ab) = 61b735be0b02e9c3da5469537e846d81d6803c58
+SHA1 (patch-ab) = 909849dbea0abd8bff39a7097d46d28d550cf298
 SHA1 (patch-ac) = 269d172fd13dbacd0fed4aa28ed2936e8ee2c4bb
 SHA1 (patch-ad) = 3947541d2230455682c18775f28f0827059dd0c8
+SHA1 (patch-ae) = 1880a2861f908f39091924eef003b4548e8cd457
diff --git a/net/kdenetwork2/patches/patch-ab b/net/kdenetwork2/patches/patch-ab
index 193fe24382f..ac2c7ce17d0 100644
--- a/net/kdenetwork2/patches/patch-ab
+++ b/net/kdenetwork2/patches/patch-ab
@@ -1,4 +1,4 @@
-$NetBSD: patch-ab,v 1.2 2001/10/15 22:46:16 skrll Exp $
+$NetBSD: patch-ab,v 1.3 2001/11/13 21:25:55 jlam Exp $
 
 --- configure.orig	Mon Sep 10 07:18:09 2001
 +++ configure
@@ -36,7 +36,7 @@ $NetBSD: patch-ab,v 1.2 2001/10/15 22:46:16 skrll Exp $
 +                ;;
 +        netbsd*)
 +                CPPFLAGS="$CPPFLAGS -D_THREAD_SAFE"
-+		USE_THREADS="-I${LOCALBASE}/PTL/include"
++		USE_THREADS="-I${BUILDLINK_DIR}/PTL/include"
 +                echo "Setting NetBSD pthread compilation options"
                  ;;
          aix*)
diff --git a/net/kdenetwork2/patches/patch-ae b/net/kdenetwork2/patches/patch-ae
new file mode 100644
index 00000000000..a05b582637d
--- /dev/null
+++ b/net/kdenetwork2/patches/patch-ae
@@ -0,0 +1,64 @@
+$NetBSD: patch-ae,v 1.1 2001/11/13 21:25:55 jlam Exp $
+
+--- libkdenetwork/kpgpbase.cpp.orig	Tue Sep  4 19:20:45 2001
++++ libkdenetwork/kpgpbase.cpp
+@@ -265,7 +265,28 @@
+               //kdDebug(5100) << "Read " << len << " bytes from pout[0]" << endl;
+               str[len] ='\0';
+               output += str;
+-            }
++            } else {
++	      /*
++	       * Apparently, on NetBSD when the child dies, the pipe begins
++	       * receiving empty data packets *before* waitpid() has signaled
++	       * that the child has died.  Also, notice that this happens
++	       * without any error bit being set in pollfd.revents (is this a
++	       * NetBSD bug???).  Notice that these anomalous packets exist
++	       * according to poll(), but have length 0 according to read().
++	       * Thus, kde can remain stuck inside this loop.
++	       *
++	       * A solution to this problem is to get out of the inner loop
++	       * when read() returns <=0.  In this way, kde has another chance
++	       * to call waitpid() to check if the child has died -- and this
++	       * time the call should succeed.
++	       *
++	       * Setting POLLHUP in pollfd.revents is not necessary, but I just
++	       * like the idea of signaling that something strange has
++	       * happened.
++	       */
++              pollout.revents |= POLLHUP;
++              break;
++	    }
+           }
+         }
+         else if (pollstatus == -1) {
+@@ -288,7 +309,28 @@
+               //kdDebug(5100) << "Read " << len << " bytes from perr[0]" << endl;
+               str[len] ='\0';
+               info += str;
+-            }
++            } else {
++	      /*
++	       * Apparently, on NetBSD when the child dies, the pipe begins
++	       * receiving empty data packets *before* waitpid() has signaled
++	       * that the child has died.  Also, notice that this happens
++	       * without any error bit being set in pollfd.revents (is this a
++	       * NetBSD bug???).  Notice that these anomalous packets exist
++	       * according to poll(), but have length 0 according to read().
++	       * Thus, kde can remain stuck inside this loop.
++	       *
++	       * A solution to this problem is to get out of the inner loop
++	       * when read() returns <=0.  In this way, kde has another chance
++	       * to call waitpid() to check if the child has died -- and this
++	       * time the call should succeed.
++	       *
++	       * Setting POLLHUP in pollfd.revents is not necessary, but I just
++	       * like the idea of signaling that something strange has
++	       * happened.
++	       */
++              pollerr.revents |= POLLHUP;
++              break;
++	    }
+           }
+         }
+         else if (pollstatus == -1) {