Re: bin/57820: devel/rcs fails on 10.0_RC2 works on 9.3

[RVP <rvp%SDF.ORG@localhost>]

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

From: RVP <rvp%SDF.ORG@localhost>
To: George Georgalis <george%galis.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, Thomas Klausner <wiz%netbsd.org@localhost>,
        Martin Husemann <martin%duskware.de@localhost>, tech-pkg%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/57820: devel/rcs fails on 10.0_RC2 works on 9.3
Date: Mon, 15 Jan 2024 00:17:29 +0000 (UTC)

 On Wed, 10 Jan 2024, George Georgalis wrote:
 
 > (fresh stable archive with 2023Q4 update on VM using /dev/sd0)
 > nb10rc2$ cd /usr/pkg/pkgsrc-release/devel/rcs/ && bmake package
 > ...
 > Making all in doc
 > gmake[1]: Entering directory
 > '/usr/pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4/doc'
 > cd .. && /usr/pkg/pkg-2023Q4-NetBSD_10.0_RC2_amd64/bin/gmake  am--refresh
 > gmake[2]: Entering directory
 > '/usr/pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4'
 > /bin/sh ./config.status --recheck
 > gmake[2]: Leaving directory
 > '/usr/pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4'
 > Updating ./version.texi
 > gmake[1]: Leaving directory
 > '/usr/pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4/doc'
 > Making all in man
 > gmake[1]: Entering directory
 > '/usr/pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4/man'
 > cd .. && /usr/pkg/pkg-2023Q4-NetBSD_10.0_RC2_amd64/bin/gmake  am--refresh
 > gmake[2]: Entering directory
 > '/usr/pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4'
 > /bin/sh ./config.status --recheck
 > gmake[2]: Leaving directory
 > '/usr/pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4'
 > date: Expected digit in canonical time
 > date: -r
 > date: ^
 > Usage: date [-ajnRu] [-d date] [-r seconds] [+format]
 > [[[[[[CC]yy]mm]dd]HH]MM[.SS]]
 >       date [-ajnRu] -f input_format new_date [+format]
 > Created REL
 > I. -I'.' rcsfreeze.1in | sed '/^\.lf /d' > rcsfreeze.1
 > sh: I.: not found
 > test -s rcsfreeze.1
 > gmake[1]: *** [Makefile:1596: rcsfreeze.1] Error 1
 > gmake[1]: Leaving directory
 > '/usr/pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4/man'
 > gmake: *** [Makefile:1392: all-recursive] Error 1
 > *** Error code 2
 >
 > Stop.
 > bmake[1]: stopped in /usr/pkg/pkgsrc-release/devel/rcs
 > *** Error code 1
 >
 > Stop.
 > bmake: stopped in /usr/pkg/pkgsrc-release/devel/rcs
 >
 
 I can tell you why this error happened: you didn't install the `text.tar.xz'
 tarball which contains `soelim'. Because soelim is missing, you get this
 error:
 
 ```
 Created REL
 I. -I'.' rcsfreeze.1in | sed '/^\.lf /d' > rcsfreeze.1
 sh: I.: not found
 ```
 
 Which triggers `REL' rule in `rcs-5.9.4/man/Makefile.am' which uses
 a GNUism:  `date -r file' to insert a date into the man-page. The
 `date -r' means something entirely different on NetBSD.
 
 (Don't know why groff is not brought in on NetBSD--it is on Ubuntu
 23.10--when pkgsrc doesn't find a suitable soelim. But, this is
 one for the pkgsrc folks to figure out...)
 
 > With bmake and base make on local device, expected behavior.
 > With pkgsrc copied to nfs, bmake works as expected but base make
 > continuously loops with the error "cd: can't cd to .."
 >
 > nb10rc2$ cd /usr/pkg/pkgsrc-release/ &&
 > /usr/pkg/pkg-2023Q4-NetBSD_10.0_RC2_amd64/bin/bmake 2>&1 | head -n1
 > ===> x11
 > nb10rc2$ cd /usr/pkg/pkgsrc-release/ && /usr/bin/make 2>&1 | head -n1
 > ===> x11
 > nb10rc2$ cd /nfs-pkg/pkgsrc-release-10rc2usr/ &&
 > /usr/pkg/pkg-2023Q4-NetBSD_10.0_RC2_amd64/bin/bmake 2>&1 | head -n1
 > ===> x11
 > nb10rc2$ cd /nfs-pkg/pkgsrc-release-10rc2usr/ && /usr/bin/make 2>&1 | head
 > -n1
 > cd: can't cd to ..
 > ...
 >
 > The 10.0 RC2 occasionally has this in dmesg but it is presumed unrelated:
 > [ 25689.996762] 192.168.50.2:/volume1/nfs-pkg: inaccurate wcc data (ctime)
 > detected, disabling wcc (ctime 1704918235.891831984 1704918235.891831984,
 > mtime 1704918235.891831984 1704918235.891831984)
 >
 
 This actually may be relevant. Does the /nfs-pkg dir. have the x (execute)
 bit set? (make will complain long before it runs any commands if it can't
 do a getcwd() on a local filesystem--don't know about NFS-mounted ones...).
 
 -RVP