Re: pkg/43602: ruby18-base won't install

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

The following reply was made to PR pkg/43602; it has been noted by GNATS.

From: Steven Bellovin <smb%cs.columbia.edu@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: pkg-manager%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
pkgsrc-bugs%NetBSD.org@localhost
Subject: Re: pkg/43602: ruby18-base won't install
Date: Sun, 11 Jul 2010 18:32:55 -0400

 On Jul 11, 2010, at 5:50 13PM, David Holland wrote:
 
 > The following reply was made to PR pkg/43602; it has been noted by =
 GNATS.
 >=20
 > From: David Holland <dholland-pbugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:=20
 > Subject: Re: pkg/43602: ruby18-base won't install
 > Date: Sun, 11 Jul 2010 21:47:40 +0000
 >=20
 > On Sun, Jul 11, 2010 at 08:45:00PM +0000, smb%cs.columbia.edu@localhost 
 > wrote:
 >>     lang/ruby18-base fails to install with up-to-date pkgsrc HEAD:
 >>=20
 >>     =3D=3D=3D> Installing for ruby18-base-1.8.7.174nb5
 >>     =3D> Creating installation directories
 >>     =3D> Running PRE-INSTALL script actions
 >>     cd /usr/pkgsrc/lang/ruby18-base/work/ruby-1.8.7-p174; =
 /usr/bin/find . \( -name '*.orig' -o -name '*.orig_dist' \)  -exec =
 /bin/rm -f {} \;
 >>     *** Error code 1
 >=20
 > This works fine on my amd64 with 5.99.29, though with USE_DESTDIR
 > turned on.
 >=20
 > The fact that it prints "*** Error code 1" without actually reporting
 > any errors leads me to suspect that something failed that ordinarily
 > shouldn't and (given that PR 43600 shows similar symptoms, and I can't
 > reproduce it either) also to wonder if you have something corrupted on
 > your system somewhere...
 >=20
 > --=20
 
 I certainly can't rule that out -- per kern/42104, I've certainly had =
 file system adventures.  I will note that I did just rebuild very many =
 packages without (other) incident.  I can build a new system, though =
 this doesn't really seem to be the best time to try today's kernel.  I =
 can also delete all packages and rebuild everything, perhaps after =
 running 'fsck -f'.  Any other suggestions?  (Well, I guess that memtest =
 is always in order.)
 
 
                --Steve Bellovin, http://www.cs.columbia.edu/~smb