NetBSD Problem Report #58098

From www@netbsd.org  Tue Apr  2 02:39:43 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7F3AD1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  2 Apr 2024 02:39:43 +0000 (UTC)
Message-Id: <20240402023941.D65CC1A923B@mollari.NetBSD.org>
Date: Tue,  2 Apr 2024 02:39:41 +0000 (UTC)
From: rwhitlock22@gmail.com
Reply-To: rwhitlock22@gmail.com
To: gnats-bugs@NetBSD.org
Subject: build.sh release fails due to missing METALOG entries
X-Send-Pr-Version: www-1.0

>Number:         58098
>Category:       misc
>Synopsis:       build.sh release fails due to missing METALOG entries
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 02 02:40:01 +0000 2024
>Last-Modified:  Mon Apr 15 03:07:24 +0000 2024
>Originator:     Robert Whitlock
>Release:        netbsd-10 cvs branch
>Organization:
>Environment:
NetBSD thinkpad 10.0 NetBSD 10.0 (THINKPAD_BUILDSH) #0: Mon Apr  1 00:52:54 EDT 2024  rob@thinkpad:/usr/src_netbsd-10_buildsh/build1-amd64-thinkpad/sys/arch/amd64/compile/THINKPAD_BUILDSH amd64
(THINKPAD_BUILDSH is just GENERIC at the moment)
>Description:
Running build.sh release as an unprivileged user fails with

obj ===> distrib/amd64/installimage-bios
--- obj-cdroms ---
--- obj ---
#    objdir  /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad/distrib/amd64/cdroms/installcd
--- obj-installimage-bios ---
--- obj ---
#    objdir  /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad/distrib/amd64/installimage-bios
clean_METALOG ===> .
--- clean_METALOG ---
clean_METALOG ===> distrib/sets
--- /usr/src_netbsd-10_buildsh/destdir/METALOG.sanitised ---
</usr/src_netbsd-10_buildsh/destdir/METALOG   /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad/tooldir.NetBSD-10.0-amd64/bin/nbawk '{ a[$1] = $0; } END { for (f in a) print a[f]; }' |   sort | /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad/tooldir.NetBSD-10.0-amd64/bin/nbmtree -CSM -k all -R time -N /usr/src_netbsd-10_buildsh/src/etc  >/usr/src_netbsd-10_buildsh/destdir/METALOG.new
nbmtree: .: missing directory in specification
nbmtree: failed at line 1 of the specification
*** Failed target: /usr/src_netbsd-10_buildsh/destdir/METALOG.sanitised
*** Failed commands:
        <${METALOG}  ${${MKUPDATE} != "no" :? ${METALOG_REMOVE_DUPLICATES} | :}  sort | ${TOOL_MTREE} -CSM -k all -R time -N ${NETBSDSRCDIR}/etc  >${METALOG}.new
        => </usr/src_netbsd-10_buildsh/destdir/METALOG   /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad/tooldir.NetBSD-10.0-amd64/bin/nbawk '{ a[$1] = $0; } END { for (f in a) print a[f]; }' |   sort | /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad/tooldir.NetBSD-10.0-amd64/bin/nbmtree -CSM -k all -R time -N /usr/src_netbsd-10_buildsh/src/etc  >/usr/src_netbsd-10_buildsh/destdir/METALOG.new
        mv ${METALOG}.new ${METALOG}.sanitised
        => mv /usr/src_netbsd-10_buildsh/destdir/METALOG.new /usr/src_netbsd-10_buildsh/destdir/METALOG.sanitised
*** [/usr/src_netbsd-10_buildsh/destdir/METALOG.sanitised] Error code 1
nbmake[4]: stopped in /usr/src_netbsd-10_buildsh/src/distrib/sets
1 error
nbmake[4]: stopped in /usr/src_netbsd-10_buildsh/src/distrib/sets
nbmake[3]: stopped in /usr/src_netbsd-10_buildsh/src
nbmake[2]: stopped in /usr/src_netbsd-10_buildsh/src
nbmake[1]: stopped in /usr/src_netbsd-10_buildsh/src

nbmake: stopped in /usr/src_netbsd-10_buildsh/src

ERROR: Failed to make release

*** BUILD ABORTED ***
1 thinkpad$ 

METALOG was missing an entry for . (the destdir) and when a line for . and ./stand makes the error go away and the build completes. The lines I manually added were:

. type=dir uname=root gname=wheel mode=0755
./stand type=dir uname=root gname=wheel mode=0755

At the time that the build quit due to the error, the METALOG also had many duplicate entries. I'm not sure whether this was expected due to the METALOG being from the middle of a build or not. It was also not sorted, but I don't know whether this is unexpected either, for the same reason. Here is a sample from the beginning of the METALOG file:

./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0/modules/compat_util type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules/compat_util/compat_util.kmod type=file uname=root gname=wheel mode=0444 size=19680 time=1711948068.0 sha256=097cb48b50163164ef96c770d58cb4e8fa5aa6294a53d2d01fd221e2bd0699c9
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules/compat_43 type=dir mode=0755
./stand/amd64/10.0/modules/compat_43/compat_43.kmod type=file uname=root gname=wheel mode=0444 size=68168 time=1711948075.0 sha256=6a383c46c203820b4860efb7d44fa281fb8c913bd8750d503efc2a457d518141
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules/compat_sysctl_09_43 type=dir mode=0755
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules/compat_sysctl_09_43/compat_sysctl_09_43.kmod type=file uname=root gname=wheel mode=0444 size=15872 time=1711948069.0 sha256=c80551743ca3aa5e93369655b6aa78c825bc4af3f31b303b5ffea2b0294b7b66
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules/compat_09 type=dir mode=0755
./stand/amd64/10.0/modules/compat_09/compat_09.kmod type=file uname=root gname=wheel mode=0444 size=15408 time=1711948071.0 sha256=e76d87437f529fb5da9bb85f58676e7e44614947ef2bc893d13c078fd313128b
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0/modules/compat_10 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules/compat_10/compat_10.kmod type=file uname=root gname=wheel mode=0444 size=3880 time=1711948073.0 sha256=afd9eda822c0f7d2ffb65bedeb82dc8694b6ff01ab59edd020a107bfa5c7729c
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules/compat_12 type=dir mode=0755
./stand/amd64/10.0/modules/compat_12/compat_12.kmod type=file uname=root gname=wheel mode=0444 size=27776 time=1711948076.0 sha256=26d0a6ef82c765fdcaebcac60bc956b4b1b113d275a161d3e3730c69c0db6e2a
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules/compat_14 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules/compat_13 type=dir mode=0755
./stand/amd64/10.0/modules/compat_14/compat_14.kmod type=file uname=root gname=wheel mode=0444 size=9048 time=1711948077.0 sha256=10692724621f25d4c95d87f89581d0952cca5c36d0223129429985eaf7a9199d
./stand/amd64/10.0/modules/compat_13/compat_13.kmod type=file uname=root gname=wheel mode=0444 size=16816 time=1711948077.0 sha256=2d2cc9b2d19fa7133414ef7b4fb87dc6edfacbb67de44e0a349082242d747612
./stand/amd64 type=dir mode=0755
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules/compat_20 type=dir mode=0755
./stand/amd64/10.0/modules/compat_16 type=dir mode=0755
./stand/amd64/10.0/modules/compat_20/compat_20.kmod type=file uname=root gname=wheel mode=0444 size=31608 time=1711948080.0 sha256=d6ef34f07730739fbae07fb0661f30586e59551c89241c373f2dd67520fb12aa
./stand/amd64/10.0/modules/compat_16/compat_16.kmod type=file uname=root gname=wheel mode=0444 size=14688 time=1711948079.0 sha256=436e2ca84622d519b1d1ecbf2cf6dde886b6cf4578fe5ad5cdb15465b5f6124d
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0/modules/compat_40 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules/compat_40/compat_40.kmod type=file uname=root gname=wheel mode=0444 size=20816 time=1711948082.0 sha256=456a53d1bad074fe5e0bf9af8a32c940d228262d11307d43b23116e197b47ee6
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules/compat_30 type=dir mode=0755
./stand/amd64/10.0/modules/compat_30/compat_30.kmod type=file uname=root gname=wheel mode=0444 size=38584 time=1711948083.0 sha256=7c4749cd87e7696982125236bbce4802f5c891710e99b92cf51d672909f50bd7
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0 type=dir mode=0755
./stand/amd64/10.0/modules/compat_60 type=dir mode=0755
./stand/amd64/10.0/modules type=dir mode=0755
./stand/amd64/10.0/modules/compat_50 type=dir mode=0755
./stand/amd64/10.0/modules/compat_60/compat_60.kmod type=file uname=root gname=wheel mode=0444 size=22560 time=1711948087.0 sha256=589a8fd546e9b51c521a1349ef9aafb27379fe701bc6fea96b4e344a902ebab2
./stand/amd64/10.0/modules/compat_50/compat_50.kmod type=file uname=root gname=wheel mode=0444 size=99320 time=1711948094.0 sha256=88a0d0c8fc419690fc244886320b49fb7f41587c6e80769c74966106433a643a
>How-To-Repeat:
cd /usr/src_netbsd-10_buildsh
rm -rf *
cvs checkout -r netbsd-10 -P src # with CVSROOT and CVS_RSH set appropriately
cvs checkout -r netbsd-10 -P xsrc
cd src

then copy the following files to /usr/src_netbsd-10_buildsh/src:

0 thinkpad$ cat mybuildtools.sh
#!/bin/sh

./build.sh -U -u -O /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad -j2 -D /usr/src_netbsd-10_buildsh/destdir tools
0 thinkpad$ cat mybuildkernel.sh
#!/bin/sh

./build.sh -U -u -O /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad -j2 -D /usr/src_netbsd-10_buildsh/destdir kernel=THINKPAD_BUILDSH
0 thinkpad$ cat mybuildmodules.sh
#!/bin/sh

./build.sh -U -u -O /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad -j2 -D /usr/src_netbsd-10_buildsh/destdir modules
0 thinkpad$ cat myinstallmodules.sh
#!/bin/sh

./build.sh -U -u -O /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad -j2 -D /usr/src_netbsd-10_buildsh/destdir installmodules=/
0 thinkpad$ cat mybuildrelease.sh
#!/bin/sh

./build.sh -U -u -O /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad -j2 -D /usr/src_netbsd-10_buildsh/destdir -x -X /usr/src_netbsd-10_buildsh/xsrc release

0 thinkpad$ 

then run:

./mybuildtools.sh
./mybuildkernel.sh

copy the "netbsd" kernel file to /netbsd
run:

./mybuildmodules.sh
./myinstallmodules.sh

reboot, then run

./mybuildrelease.sh
>Fix:
Fix METALOG generation/handling somehow.

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/58098: build.sh release fails due to missing METALOG entries
Date: Tue, 2 Apr 2024 07:18:58 +0200

 On Tue, Apr 02, 2024 at 02:40:01AM +0000, rwhitlock22@gmail.com wrote:
 > ./build.sh -U -u -O /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad -j2 -D /usr/src_netbsd-10_buildsh/destdir -x -X /usr/src_netbsd-10_buildsh/xsrc release

 You are using -u so this has to be the effect of something previously
 gone wrong and the "update" build not fixing it.

 I would remove the whole object dir once
 (rm -rf /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad)
 and try again with a clean build.

 Martin

From: Rob Whitlock <rwhitlock22@gmail.com>
To: gnats-bugs@netbsd.org
Cc: misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: misc/58098: build.sh release fails due to missing METALOG entries
Date: Tue, 2 Apr 2024 09:15:09 -0400

 > On Apr 2, 2024, at 1:20 AM, Martin Husemann <martin@duskware.de> =
 wrote:
 >=20
 > The following reply was made to PR misc/58098; it has been noted by =
 GNATS.
 >=20
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@netbsd.org
 > Cc:=20
 > Subject: Re: misc/58098: build.sh release fails due to missing METALOG =
 entries
 > Date: Tue, 2 Apr 2024 07:18:58 +0200
 >=20
 > On Tue, Apr 02, 2024 at 02:40:01AM +0000, rwhitlock22@gmail.com wrote:
 >> ./build.sh -U -u -O /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad =
 -j2 -D /usr/src_netbsd-10_buildsh/destdir -x -X =
 /usr/src_netbsd-10_buildsh/xsrc release
 >=20
 > You are using -u so this has to be the effect of something previously
 > gone wrong and the "update" build not fixing it.
 >=20
 > I would remove the whole object dir once
 > (rm -rf /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad)
 > and try again with a clean build.
 >=20
 > Martin
 >=20

 I already did that. Note the part at the beginning of the "How to =
 repeat" section that said:

 cd /usr/src_netbsd-10_buildsh
 rm -rf *=

From: Martin Husemann <martin@duskware.de>
To: Rob Whitlock <rwhitlock22@gmail.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: misc/58098: build.sh release fails due to missing METALOG entries
Date: Tue, 2 Apr 2024 16:59:18 +0200

 The METALOG file will not be cleaned if you use -u for different targets.
 This is not supported (and in general not needed).

 You need to drop -u from your scripts or combine them into a single build.sh
 invocation.

 See this section in the top level Makefile:

 ---8<---
 # Delete or sanitise a leftover METALOG from a previous build.
 clean_METALOG: .PHONY .MAKE
 .if ${MKUPDATE} != "no"
         ${MAKEDIRTARGET} distrib/sets clean_METALOG
 .endif
 --->8---

 So instead of doing it in tiny pieces, combine the whole invocation into
 something like:


 ./build.sh -U -O /usr/src_netbsd-10_buildsh/build1-amd64-thinkpad -j2 -D /usr/src_netbsd-10_buildsh/destdir -x -X /usr/src_netbsd-10_buildsh/xsrc release kernel=THINKPAD_BUILDSH


 When something goes wrong and you want to re-try, you can add -u.

 When it works, copy the kernel to /netbsd and do the "installmodules" step
 with -u.

 You should not reboot with new kernel but modules not yet updated (usually
 harmless, but in general not).

 Martin

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Martin Husemann <martin@duskware.de>
Cc: Rob Whitlock <rwhitlock22@gmail.com>,
	gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: misc/58098: build.sh release fails due to missing METALOG entries
Date: Tue, 2 Apr 2024 17:37:30 +0000

 This issue isn't about the order of operations for building and
 installing an updated NetBSD -- the issue is that build.sh modules
 leaves a broken METALOG file lying around, which causes other build.sh
 operations to fail.

 Just doing

 ./build.sh -u ... tools
 ./build.sh -u ... modules
 ./build.sh -u ... release

 is probably enough to reproduce the problem, without any install
 steps.

From: Rob Whitlock <rwhitlock22@gmail.com>
To: gnats-bugs@netbsd.org
Cc: misc-bug-people@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: misc/58098: build.sh release fails due to missing METALOG entries
Date: Fri, 5 Apr 2024 08:15:35 -0400

 > On Apr 2, 2024, at 1:40 PM, Taylor R Campbell <riastradh@NetBSD.org> =
 wrote:
 >=20
 > The following reply was made to PR misc/58098; it has been noted by =
 GNATS.
 >=20
 > From: Taylor R Campbell <riastradh@NetBSD.org>
 > To: Martin Husemann <martin@duskware.de>
 > Cc: Rob Whitlock <rwhitlock22@gmail.com>,
 > 	gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
 > Subject: Re: misc/58098: build.sh release fails due to missing METALOG =
 entries
 > Date: Tue, 2 Apr 2024 17:37:30 +0000
 >=20
 > This issue isn't about the order of operations for building and
 > installing an updated NetBSD -- the issue is that build.sh modules
 > leaves a broken METALOG file lying around, which causes other build.sh
 > operations to fail.
 >=20
 > Just doing
 >=20
 > ./build.sh -u ... tools
 > ./build.sh -u ... modules
 > ./build.sh -u ... release
 >=20
 > is probably enough to reproduce the problem, without any install
 > steps.
 >=20

 Assuming that you meant that deleting -U would reproduce the problem, =
 this is incorrect. Removing -U requires the build to be done as root. =
 Building as an unprivileged user without -U fails with an error saying =
 as such. When -U is removed and the commands are run as root with fresh =
 -O and -D directories, they complete successfully. This makes sense =
 because METALOG is only generated in the case of an unprivileged build =
 because the build system can't set permissions willy nilly.=

From: Martin Husemann <martin@duskware.de>
To: Rob Whitlock <rwhitlock22@gmail.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: misc/58098: build.sh release fails due to missing METALOG entries
Date: Fri, 5 Apr 2024 14:47:02 +0200

 On Fri, Apr 05, 2024 at 08:15:35AM -0400, Rob Whitlock wrote:
 > Assuming that you meant that deleting -U would reproduce the problem,
 > this is incorrect.

 No, he meant that your reproduction instruction where unecessarily complex
 and just running the 3 operations tools, modules, release in that order
 would reproduce it - which is probably true and points at the "modules"
 operation leaving a broken METALOG file.

 This is a bug and should be fixed.

 My earlier point (slightly unrelated to this bug) is that "release" is enough
 for this whole thing, you do neither need "tools" nor "modules".

 The default operation I use for everything but very special cases is "distsets".

 So you could collapse your setting to just

 	build.sh ..... distsets kernel=....

 and work around the bug that way.

 Martin

From: Rob Whitlock <rwhitlock22@gmail.com>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: misc/58098: build.sh release fails due to missing METALOG entries
Date: Mon, 8 Apr 2024 10:19:12 -0400

 > On Apr 5, 2024, at 8:47 AM, Martin Husemann <martin@duskware.de> =
 wrote:
 >=20
 > On Fri, Apr 05, 2024 at 08:15:35AM -0400, Rob Whitlock wrote:
 >> Assuming that you meant that deleting -U would reproduce the problem,
 >> this is incorrect.
 >=20
 > No, he meant that your reproduction instruction where unecessarily =
 complex
 > and just running the 3 operations tools, modules, release in that =
 order
 > would reproduce it - which is probably true and points at the =
 "modules"
 > operation leaving a broken METALOG file.

 I see. I can confirm that just running those three operations does =
 reproduce the problem.

 > This is a bug and should be fixed.

 I have included a patch below that fixes the problem, as well as a typo =
 and it also writes the owner and group for other directories, which were =
 missing in the METALOG. I also included the mode, even though 0755 is =
 the default and it was being written into the METALOG already.

 The patch does not address the issue that directories are written to =
 METALOG redundantly, however this doesn't seem to cause an issue because =
 METLOG.sanitized is created without the duplicates.

 > My earlier point (slightly unrelated to this bug) is that "release" is =
 enough
 > for this whole thing, you do neither need "tools" nor "modules".
 >=20
 > The default operation I use for everything but very special cases is =
 "distsets".
 >=20
 > So you could collapse your setting to just
 >=20
 > 	build.sh ..... distsets kernel=3D....
 >=20
 > and work around the bug that way.
 >=20
 > Martin

 That's good to know, thanks.

 Index: share/mk/bsd.kmodule.mk
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /cvsroot/src/share/mk/bsd.kmodule.mk,v
 retrieving revision 1.81
 diff -r1.81 bsd.kmodule.mk
 209c209
 < # Ensure these are recorded properly in METALOG on unprived installes:
 ---
 > # Ensure these are recorded properly in METALOG on unprived installs:
 242a243,244
 > 	echo '. type=3Ddir uname=3Droot gname=3Dwheel mode=3D0755' | =
 ${METALOG.add}
 > 	echo './stand type=3Ddir uname=3Droot gname=3Dwheel mode=3D0755' =
 | ${METALOG.add}
 245c247
 < 		${INSTALL_DIR} ${DESTDIR}$$d; \
 ---
 > 		${INSTALL_DIR} -o root -g wheel -m 0755 ${DESTDIR}$$d; \=

From: Rob Whitlock <rwhitlock22@gmail.com>
To: gnats-bugs@netbsd.org
Cc: misc-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: misc/58098: build.sh release fails due to missing METALOG entries
Date: Sun, 14 Apr 2024 23:02:48 -0400

 --Apple-Mail=_31BEBA01-8262-4223-97A5-8DDA861653FB
 Content-Transfer-Encoding: 7bit
 Content-Type: text/plain;
 	charset=us-ascii


 > On Apr 8, 2024, at 10:20 AM, Rob Whitlock <rwhitlock22@gmail.com> wrote:
 --Apple-Mail=_31BEBA01-8262-4223-97A5-8DDA861653FB
 Content-Disposition: attachment;
 	filename=METALOG.diff
 Content-Type: application/octet-stream;
 	x-unix-mode=0644;
 	name="METALOG.diff"
 Content-Transfer-Encoding: 7bit

 Index: share/mk/bsd.kmodule.mk
 ===================================================================
 RCS file: /cvsroot/src/share/mk/bsd.kmodule.mk,v
 retrieving revision 1.81
 diff -u -r1.81 bsd.kmodule.mk
 --- share/mk/bsd.kmodule.mk	7 Aug 2022 23:42:09 -0000	1.81
 +++ share/mk/bsd.kmodule.mk	14 Apr 2024 12:06:03 -0000
 @@ -206,10 +206,12 @@
  _INST_DIRS+=	/netbsd/modules
  KMODULEDIR=	/netbsd/modules/${KMOD}
  .else
 -# Ensure these are recorded properly in METALOG on unprived installes:
 +# Ensure these are recorded properly in METALOG on unprived installs:
  _OSRELEASE!=	${HOST_SH} $S/conf/osrelease.sh -k
  KMODULEARCHDIR?= ${MACHINE}
 -_INST_DIRS=	/stand/${KMODULEARCHDIR}
 +_INST_DIRS=	/
 +_INST_DIRS+=	/stand
 +_INST_DIRS+=	/stand/${KMODULEARCHDIR}
  _INST_DIRS+=	/stand/${KMODULEARCHDIR}/${_OSRELEASE}
  _INST_DIRS+=	/stand/${KMODULEARCHDIR}/${_OSRELEASE}/modules
  KMODULEDIR=	/stand/${KMODULEARCHDIR}/${_OSRELEASE}/modules/${KMOD}
 @@ -242,7 +244,7 @@
  	${_MKTARGET_INSTALL}
  	dirs=${_INST_DIRS:Q}; \
  	for d in $$dirs; do \
 -		${INSTALL_DIR} ${DESTDIR}$$d; \
 +		${INSTALL_DIR} -o root -g wheel -m 0755 ${DESTDIR}$$d; \
  	done
  	${INSTALL_FILE} -o ${KMODULEOWN} -g ${KMODULEGRP} -m ${KMODULEMODE} \
  		${.ALLSRC} ${.TARGET}

 --Apple-Mail=_31BEBA01-8262-4223-97A5-8DDA861653FB
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii

 >> On Apr 5, 2024, at 8:47 AM, Martin Husemann <martin@duskware.de> =3D
 > wrote:

 [snip]

 >> This is a bug and should be fixed.
 >=20
 > I have included a patch below that fixes the problem, as well as a =
 typo =3D
 > and it also writes the owner and group for other directories, which =
 were =3D
 > missing in the METALOG. I also included the mode, even though 0755 is =
 =3D
 > the default and it was being written into the METALOG already.
 >=20
 > The patch does not address the issue that directories are written to =3D=

 > METALOG redundantly, however this doesn't seem to cause an issue =
 because =3D
 > METLOG.sanitized is created without the duplicates.

 I somehow missed that the previous patch fails when DESTDIR doesn't =
 exist. The attached patch corrects this.


 --Apple-Mail=_31BEBA01-8262-4223-97A5-8DDA861653FB--

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.