Re: pkg/39129: devel/scmcvs does not work correctly on IRIX

[David Holland <dholland-pbugs%netbsd.org@localhost>]

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

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/39129: devel/scmcvs does not work correctly on IRIX
Date: Mon, 10 Aug 2015 00:18:41 +0000

 On Fri, Jul 11, 2008 at 03:50:56PM +0100, Stuart Shelton wrote:
  > That was my initial thought - but another totally separate (IRIX)
  > system is having identical problems with identical files(!)
  > 
  > I've also checked the filesystem, and there are no ACLs anywhere
  > within the pkgsrc tree on either machine...
  > 
  > It's obscure for certain, but I'm convinced that this is a CVS problem...
  > 
  > 
  > The 'par' output contains:
  > [...]
  > 278657mS[  0]             cvs(2669024): write(2, "cvs update: Updating
  > archivers/unzip", 36) = 36
  > 278658mS[  0]             cvs(2669024): write(2, "\n", 1) = 1
  > 278658mS[  0]             cvs(2669024): write(2, "cvs [update
  > aborted]: cannot open file Makefile for comparing: Permission denied",
  > 80) = 80
 
 There's no open call in there, so assuming the trace is correct the
 problem is very limited in scope.
 
 The string "cannot open file %s for comparing" appears three times in
 the CVS source (ignoring e.g. the OS/2 code), two of which are
 immediately after failing calls to open(2). The other one is
 immediately after a failing call to fopen(3).
 
 The only reasonable conclusion (other than that the problem has been
 fixed upstream in the meantime) is that fopen is failing before
 actually trying to open anything, and the only reasonable conclusion
 about that given the circumstances is that cvs thinks the file is
 binary and passes "rb" instead of "r" as the fopen mode and that Irix
 doesn't like that for some reason even though it's standard. In that
 case the "Permission denied" is probably just an uninitialized errno
 value.
 
 There have been two updates since this PR was filed though so maybe
 the issue has been fixed upstream.
 
 So, if you still care, can still test, and still see the problem, try
 (1) setting errno = 0 before that fopen call (it is on line 5734 of
 src/rcs.c) and see if the "error" message changes to "Success" or
 equivalent, and (2) changing FOPEN_BINARY_READ to just "r" at the
 bottom of lib/system.h and seeing if that makes the problem go away.
 
 If that doesn't work, I'm rather stumped.
 
 Conversely, if you no longer care or can't reproduce it, let me know
 and I'll close the PR.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost