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

[George Georgalis <george%galis.org@localhost>]

On Thu, Jan 4, 2024 at 11:10 PM Thomas Klausner <wiz%netbsd.org@localhost> wrote:
> Subject: Re: bin/57820: devel/rcs fails on 10.0_RC2 works on 9.3
> Date: Fri, 5 Jan 2024 08:09:17 +0100
>  On Fri, Jan 05, 2024 at 06:40:00AM +0000, george%galis.org@localhost wrote:
>  > >Number:         57820
>  > >Category:       bin
>  > >Synopsis:       devel/rcs fails on 10.0_RC2 works on 9.3
>
>  > bmake clean clean-depends package
>
>  On NetBSD, you don't need to install or use 'bmake' for pkgsrc, the
>  native make is the same tool.

I'm using pkgsrc to enable an app to run on Darwin/Linux/NetBSD, for
consistency and simplicity I'm using the same scripts to bootstrap
pkgsrc on each platform and install the base packages (dependencies).
There shouldn't be any problems using pkgsrc bmake or rcs? The
checkout is in NFS to recycle the source. I need to learn
cross-compiling, for now, I'm purging ./packages/All/* when switching
platforms, and always doing bmake clean clean-depends for builds. Of
course LOCALBASE is different for each platform:

LOCALBASE="$p/$(sed 's/^Tpkgsrc/pkg/' <$pkgsrc/CVS/Tag)-$(uname -msr |
tr ' ' '_' )"
./bootstrap --prefix "$LOCALBASE" --unprivileged --prefer-pkgsrc yes
--make-jobs 8

I think that is sufficient to keep the source clean?
LOCALBASE/{bin,sbin} entries are placed in the front of the path.

I could make a fresh source checkout, to further isolate the rcs
issue, but don't think there would be anything to gain?

>  > ...
>  > gmake[1]: Entering directory '/nfs-pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4/man'
>  > cd .. && /nfs-pkg/pkg-2023Q4-NetBSD_10.0_RC2_amd64/bin/gmake  am--refresh
>  > gmake[2]: Entering directory '/nfs-pkg/pkgsrc-release/devel/rcs/work/rcs-5.9.4'
>  > /bin/sh ./config.status --recheck
>  > gmake[2]: Leaving directory '/nfs-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
>
>  Is the time setup correctly on the system?

I believe so, locale and localtime are listed below, along with
(identical?) 2023Q4 bootstrap on a 9.3 system, without issue. NTPd is
working. Is there anything else to time?

./work/.work.log is useless. How else can I diagnose this rcs issue?

A ton of other packages are building fine, notably though, not rust
and go118. No errors in dmesg. These are minimally configured systems.

srv-63b7# uname -a ; locale ; ls -l /etc/localtime
NetBSD srv-63b7 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug  4 15:30:37 UTC
2022  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC
amd64
LANG=""
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=""
lrwxr-xr-x  1 root  wheel  39 Jan  5  2023 /etc/localtime ->
/usr/share/zoneinfo/America/Los_Angeles

nb10rc2# uname -a ; locale ; ls -l /etc/localtime
NetBSD nb10rc2.asus 10.0_RC2 NetBSD 10.0_RC2 (GENERIC) #0: Mon Jan  1
14:04:52 UTC 2024
mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC
amd64
LANG=""
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=""
lrwxr-xr-x  1 root  wheel  39 Jan  4 11:38 /etc/localtime ->
/usr/share/zoneinfo/America/Los_Angeles



-- 
George Georgalis, (415) 894-2710, http://www.galis.org/