Re: extra files in DESTDIR
bch writes: questions I still wonder about: >>> what arch are you building for >>> what was the build host >>> what was your build.sh line > So I nuked the /usr/obj directory completely (which contained the DESTDIR), > used the -A switch to confirm cvs co is properly tracking -current, and ran > a single job (e.g. no “-j4”) and tools failed to build. I ended up deleting > the tools source completely and re-pulling and it then built properly. I This is a clue. But perhaps you didn't delete the objdir for the tools. After cvs up -A, removal and re-checkout should not change. Do cvs up -I \! and save it. There should be no output, but you might have built files in the tree. Also from top level cvs diff -r HEAD -I \! and again output should be empty. > went on to build a distribution, and ended up at the same place - failed > the final checkflist. The offending file is a regular file, while it’s > analog in my running system is a symlink, which is another curiousity and > perhaps a clue? I’m still at a loss. I captured the build w script(1) so I > may be able to provide more information on request. See src/libexec/ld.elf_so and read the Makefile. I just removed ld.elf_so from my destdir and re-ran make install (via using the arch-specific nbmake in the tooldir) and it worked fine to recreate the symlink. Check that directory specificially in your checkout for not having spurious files. signature.asc Description: PGP signature
Re: extra files in DESTDIR
It *was* worse when I had errant cvs tags in effect, and so part of the tree was updated differently than the rest, but thats sorted out now. Since you readily acknowledge having had some errant tagging issues in your tree previously, I would just delete and re-checkout your source tree. At the very least do a ``cvs up -A'' ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: extra files in DESTDIR
Bch wrote: > >I've been getting this (and worse) for a while, and just living with it: > >=== 1 extra files in DESTDIR = >Files in DESTDIR but missing from flist. >File is obsolete or flist is out of date ? >-- >./usr/libexec/ld.elf_so >= end of 1 extra files === > >It *was* worse when I had errant cvs tags in effect, and so part >of the tree was updated differently than the rest, but thats sorted >out now. I think your tree is still messed up. That file should be a symlink to /libexec/ld.elf_so, what is it in the DESTDIR that you have built ? The flist entry should be the final line of src/distrib/sets/lists/base/shl.mi.
Re: extra files in DESTDIR
Bch writes: > I've been getting this (and worse) for a while, and just living with it: > > === 1 extra files in DESTDIR = > Files in DESTDIR but missing from flist. > File is obsolete or flist is out of date ? > -- > ./usr/libexec/ld.elf_so > = end of 1 extra files === You didn't specify: do you really mean -current what date did you update what arch are you building for what was the build host what was your build.sh line > It *was* worse when I had errant cvs tags in effect, and so part > of the tree was updated differently than the rest, but thats sorted > out now. Do you mean that you did "cvs up -dP" and got no output? (Or at least only P/U and not M?) It might be good to rm -rf your objdir and destdir and see if this presents on a fresh build. > This particular extra file is a troublesome long-running issue for > me though -- I've ignored it until now, but I'm trying to build a > release to update a remote machine and this is sticking point. > Deleting the file doesn't work - it will re-appear. What do I need > to look at or do to solve this? I have a netbsd-9 system on which I built current for amd64. My destdir has > ls -l /usr/obj/gdt-current/destdir/amd64/usr/libexec/ld.elf_so lrwxr-xr-x 1 gdt wheel 18 Oct 18 00:01 /usr/obj/gdt-current/destdir/amd64/usr/libexec/ld.elf_so -> /libexec/ld.elf_so starting from src/distrib, I find ./lists/base/md.amd64:./libexec/ld.elf_so-i386 base-sys-shlib compat,pic ./lists/base/md.amd64:./usr/libexec/ld.elf_so-i386 base-sys-shlib compat,pic so things look fine to me. signature.asc Description: PGP signature
extra files in DESTDIR
I've been getting this (and worse) for a while, and just living with it: === 1 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/libexec/ld.elf_so = end of 1 extra files === It *was* worse when I had errant cvs tags in effect, and so part of the tree was updated differently than the rest, but thats sorted out now. This particular extra file is a troublesome long-running issue for me though -- I've ignored it until now, but I'm trying to build a release to update a remote machine and this is sticking point. Deleting the file doesn't work - it will re-appear. What do I need to look at or do to solve this? Cheers, -bch
MKDEBUG=yes results in hundreds of extra files in $DESTDIR
Looks like recent changes to module .mk files doesn't work with MKDEBUG=yes ... === 615 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/libdata/debug/stand/amd64-xen ./usr/libdata/debug/stand/amd64-xen/9.99.59 ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules ... ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules/zl10353 ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules/zl10353/zl10353.kmod.debug ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules/zlib ./usr/libdata/debug/stand/amd64-xen/9.99.59/modules/zlib/zlib.kmod.debug = end of 615 extra files === --- checkflist --- *** [checkflist] Error code 1 ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build fails on extra files in DESTDIR, what does that mean?
from Ian D. Leroux: Passing the -r option to ./build.sh will force a clean of DESTDIR. That's good to know! I just went through ./build.sh again, see -r option clears both DESTDIR and TOOLDIR. I think the DESTDIR must have still had stuff from 6.99.40. Tom
Build fails on extra files in DESTDIR, what does that mean?
Trying to build NetBSD 7.99.10 amd64, i386, from 7.99.7 installation was
stopped by
===
checkflist === distrib/sets
cd /BETA1/netbsd-HEAD/usr/src/distrib/sets
DESTDIR=/BETA1/netbsd-HEAD/usr/src/../obj/BETA1/netbsd-HEAD/usr/src/destdir.amd64
MACHINE=amd64 MACHINE_ARCH=x86_64
AWK=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbawk
CKSUM=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbcksum
DB=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbdb HOST_SH=/bin/sh
MAKE=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbmake
MKTEMP=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbmktemp
MTREE=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbmtree
PAX=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbpax COMPRESS_PROGRAM=gzip
GZIP=-n PKG_CREATE=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbpkg_create
SED=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbsed
TSORT=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbtsort\ -q /bin/sh
/BETA1/netbsd-HEAD/usr/src/distrib/sets/checkflist -L base,x -M
/BETA1/netbsd-HEAD/usr/src/../obj/BETA1/netbsd-HEAD/usr/src/destdir.amd64/METALOG.sanitised
=== 18 extra files in DESTDIR =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./lib/liblzma.so.1
./lib/liblzma.so.1.1
./usr/lib/i386/libamu.so.4
./usr/lib/i386/libamu.so.4.0
./usr/lib/i386/liblua.so.1
./usr/lib/i386/liblua.so.1.0
./usr/lib/i386/liblzma.so.1
./usr/lib/i386/liblzma.so.1.1
./usr/lib/i386/libssh.so.22
./usr/lib/i386/libssh.so.22.0
./usr/lib/libamu.so.4
./usr/lib/libamu.so.4.0
./usr/lib/liblua.so.1
./usr/lib/liblua.so.1.0
./usr/lib/liblzma.so.1
./usr/lib/liblzma.so.1.1
./usr/lib/libssh.so.22
./usr/lib/libssh.so.22.0
= end of 18 extra files ===
*** Failed target: checkflist
*** Failed command: cd /BETA1/netbsd-HEAD/usr/src/distrib/sets
DESTDIR=/BETA1/netbsd-HEAD/usr/src/../obj/BETA1/netbsd-HEAD/usr/src/destdir.amd64
MACHINE=amd64 MACHINE_ARCH=x86_64
AWK=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbawk
CKSUM=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbcksum
DB=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbdb HOST_SH=/bin/sh
MAKE=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbmake
MKTEMP=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbmktemp
MTREE=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbmtree
PAX=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbpax COMPRESS_PROGRAM=gzip
GZIP=-n PKG_CREATE=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbpkg_create
SED=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbsed
TSORT=/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbtsort\ -q /bin/sh
/BETA1/netbsd-HEAD/usr/src/distrib/sets/checkflist -L base,x -M
/BETA1/netbsd-HEAD/usr/src/../obj/BETA1/netbsd-HEAD/usr/src/destdir.amd64/METALOG.sanitised
*** Error code 1
Stop.
nbmake[1]: stopped in /BETA1/netbsd-HEAD/usr/src/distrib/sets
*** Failed target: distribution
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=;
real=/BETA1/netbsd-HEAD/usr/src ;; *) this=${dir}/;
real=/BETA1/netbsd-HEAD/usr/src/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget distrib/sets checkflist
*** Error code 1
Stop.
nbmake: stopped in /BETA1/netbsd-HEAD/usr/src
ERROR: Failed to make distribution
*** BUILD ABORTED ***
=== build.sh command:./build.sh -m amd64 -B nb7-20150421 -M ../obj -T
../tooldir -x -X ../xsrc -U distribution kernel=GENERIC
=== build.sh started:Tue Apr 21 11:02:41 UTC 2015
=== NetBSD version: 7.99.10
=== MACHINE: amd64
=== MACHINE_ARCH:x86_64
=== Build platform: NetBSD 7.99.7 amd64
=== HOST_SH: /bin/sh
=== BUILDID: nb7-20150421
=== /BETA1/netbsd-HEAD/usr/src/../tooldir/bin/nbmake outdated (older than
usr.bin/make/job.c), needs building.
=== Bootstrapping nbmake
I thought make cleandir was automatic, but believe I had this problem before.
Similar failure with i386 build.
Now I cleaned out the obj directories (rm -R) and also ran newfs on the 7.99.7
installations, amd64 and i386.
Reason for newfs was to get rid of native Xorg and switch to modular pkgsrc
Xorg (too drastic, maybe, but there were no packages installed).
So I update src tree and will rebuild from 7.99.1 amd64, installing into
separate GPT partition.
But I am still curious about a build failing on extra files in DESTDIR and how
to avoid it, remember this happening before in NetBSD but not FreeBSD.
Now I think I will try to build for amd64 before deciding whether to also build
for i386.
Tom
Re: Build fails on extra files in DESTDIR, what does that mean?
On Tue, Apr 28, 2015, at 07:40, Thomas Mueller wrote: But I am still curious about a build failing on extra files in DESTDIR and how to avoid it, remember this happening before in NetBSD but not FreeBSD. ./build.sh does an automatic make cleandir by default (if you don't pass the -u option), but this does not delete files in DESTDIR (in some cases, DESTDIR may refer to a running system, and you definitely don't want to clean everything out of there when you tidy up your source tree). You have to wipe out the destdir manually if there are extra files there. (I think there's another make target for that purpose, but it's been a few months since I've used it). -- IDL
Re: Build fails on extra files in DESTDIR, what does that mean?
On Tue, 28 Apr 2015 10:21:07 +0200 Ian D. Leroux idler...@fastmail.fm wrote: On Tue, Apr 28, 2015, at 07:40, Thomas Mueller wrote: But I am still curious about a build failing on extra files in DESTDIR and how to avoid it, remember this happening before in NetBSD but not FreeBSD. ./build.sh does an automatic make cleandir by default (if you don't pass the -u option), but this does not delete files in DESTDIR (in some cases, DESTDIR may refer to a running system, and you definitely don't want to clean everything out of there when you tidy up your source tree). You have to wipe out the destdir manually if there are extra files there. (I think there's another make target for that purpose, but it's been a few months since I've used it). Passing the -r option to ./build.sh will force a clean of DESTDIR. -- IDL
Re: Extra files in DESTDIR with MKRUMP=no
On Thu, 29 Jan 2015 10:39:42 + (GMT) Robert Swindells r...@fdy2.co.uk wrote: idler...@fastmail.fm wrote: I also build with MKRUMP=no but have the following extra patch in my local tree: Robert Swindells Index: tests/mi === RCS file: /cvsroot/src/distrib/sets/lists/tests/mi,v retrieving revision 1.610 diff -u -r1.610 mi --- tests/mi14 Jan 2015 22:25:05 - 1.610 +++ tests/mi29 Jan 2015 10:41:34 - @@ -3146,7 +3146,7 @@ ./usr/tests/net/in_cksum/t_in_cksumtests-net-tests atf ./usr/tests/net/in_cksum/in_cksum tests-net-tests atf ./usr/tests/net/mcast tests-net-tests -./usr/tests/net/mcast/Atffile tests-net-tests atf,rump +./usr/tests/net/mcast/Atffile tests-net-tests atf ./usr/tests/net/mcast/Kyuafile tests-net-tests atf,rump,kyua ./usr/tests/net/mcast/t_mcast tests-net-tests atf ./usr/tests/net/mpls tests-net-tests I've now convinced myself that this is the correct (and not just the immediately convenient) fix. The t_mcast test has no dependence on rump that I can see, src/tests/net/Makefile clearly builds it even when MKRUMP=no (thus generating the corresponding Atffile), so the presence of the Atffile is not dependent on rump either. If you (Mr Swindells) are not intending to do so yourself, I'll file a PR (crediting you for the patch of course) so that this doesn't get forgotten about in the list archives. -- IDL
Re: Extra files in DESTDIR with MKRUMP=no
Sorry, forgot to cc the list when first sending this ... On Thu, 29 Jan 2015 10:39:42 + (GMT) Robert Swindells r...@fdy2.co.uk wrote: idler...@fastmail.fm wrote: On Mon, 8 Dec 2014 22:12:52 +0100 Ian D. Leroux idler...@fastmail.fm wrote: ./build.sh tools ./build.sh kernel=SCRAMEUSTACHE ./build.sh distribution fails with === 1 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/net/mcast/Atffile = end of 1 extra files === I also build with MKRUMP=no but have the following extra patch in my local tree: Index: tests/mi === RCS file: /cvsroot/src/distrib/sets/lists/tests/mi,v retrieving revision 1.610 diff -u -r1.610 mi --- tests/mi14 Jan 2015 22:25:05 - 1.610 +++ tests/mi29 Jan 2015 10:41:34 - @@ -3146,7 +3146,7 @@ ./usr/tests/net/in_cksum/t_in_cksumtests-net-tests atf ./usr/tests/net/in_cksum/in_cksum tests-net-tests atf ./usr/tests/net/mcast tests-net-tests -./usr/tests/net/mcast/Atffile tests-net-tests atf,rump +./usr/tests/net/mcast/Atffile tests-net-tests atf ./usr/tests/net/mcast/Kyuafile tests-net-tests atf,rump,kyua ./usr/tests/net/mcast/t_mcast tests-net-tests atf ./usr/tests/net/mpls tests-net-tests Thank you for pointing out the fix so specifically. Is there any reason not to commit such a correction to the tree? -- IDL
Re: Extra files in DESTDIR with MKRUMP=no
On Mon, 8 Dec 2014 22:12:52 +0100 Ian D. Leroux idler...@fastmail.fm wrote: Sorry, someone pointed this out a few weeks back and I did say I would fix it but got distracted, will take a look. Ah, I missed it the first time it was mentioned. Sorry for the duplicate report. Note that usr/tests/net/mcast/Atffile is not obviously rump-related, so there may be several things going on here. The problem with rump manpages is now resolved (my thanks to Justin Cormack), but there's still something wrong with the set lists. With amd64 CURRENT as of last night and after deleting the entire contents of obj/ and tools/, ./build.sh tools ./build.sh kernel=SCRAMEUSTACHE ./build.sh distribution fails with === 1 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/net/mcast/Atffile = end of 1 extra files === Since others are apparently not seeing this, it may be related to a non-default build configuration. The section of mk.conf which is active for non-pkg builds includes: MKHESIOD=no MKHTML=no MKIPFILTER=no MKISCSI=no MKKERBEROS=no MKKMOD=no MKLDAP=no MKPF=no MKRUMP=no MKUNPRIVED=yes MKX11=yes MKYP=no MKZFS=no TOOLDIR=/home/tools BSDOBJDIR=/home/obj BSDSRCDIR=/home/src Is there an easy way to find out what part of the source tree or build installed the file to DESTDIR, and what part failed to add it to the set lists? -- IDL
