Re: amd64 -current build failure
Glad to hear it wasn't something stupid I have done... I see that - it has been going through the build today - not yet finished. Thanks, Chavdar On Wed, 13 May 2015 at 13:26 Christos Zoulas chris...@astron.com wrote: In article CAG0OUxj83ke25NM2O6MnWpbKbF77y09ET= 0ae1osn8w25b0...@mail.gmail.com, Chavdar Ivanov ci4...@gmail.com wrote: Hi, My overnight build of -current (only amd64 on this machine) failed due to lack of disk space. The day before there was more than 200GB free on the filesystem in question. I found the following file at the end: ... -- total 473048080 -rw-r--r-- 1 sysbuild sysbuild 68521 May 11 18:20 .depend -rw-r--r-- 1 sysbuild sysbuild 242170084173 May 13 03:24 cgram.c -rw-r--r-- 1 sysbuild sysbuild 3190 May 11 18:20 cgram.d -rw-r--r-- 1 sysbuild sysbuild 2125 May 13 00:53 cgram.h -rw-r--r-- 1 sysbuild sysbuild 94672 May 11 18:20 cgram.lo in /home/sysbuild/amd64/obj/home/sysbuild/src/tools/lint1 - it seems the default configuration of sysbuild somehow places one more copy of src under the object subdirectory; as about the cgram.c file, it looks properly generated .c source, apart from the fact that it does not finish. Any suggestions as to why this might have happened? I build the day before the system - not via cron as in this case, but by manually executing the command line which is normally started by cron. This has been fixed; make cleandir in /usr/src/tools/lint1 christos
Re: amd64 -current build failure
In article CAG0OUxjTbSQZF48uDHkheM5ZEgQoPqnBPXcxRs=tjuzbeaj...@mail.gmail.com, Chavdar Ivanov ci4...@gmail.com wrote: -=-=-=-=-=- Glad to hear it wasn't something stupid I have done... I see that - it has been going through the build today - not yet finished. If there is any consolation, my cgram.c file was as large as yours... christos
daily CVS update output
Updating src tree: P src/doc/3RDPARTY P src/doc/TODO.clang P src/lib/libedit/chartype.h P src/lib/libedit/map.c P src/lib/libedit/tty.c P src/lib/libm/src/s_copysign.c P src/lib/libm/src/s_copysignl.c P src/share/man/man9/devsw_attach.9 P src/share/man/man9/module.9 P src/sys/arch/arm/arm/cpufunc.c P src/sys/arch/arm/arm/cpufunc_asm_pj4b.S P src/sys/arch/arm/include/cpufunc_proto.h P src/sys/arch/arm/marvell/armadaxp.c P src/sys/arch/arm/marvell/armadaxpreg.h P src/sys/arch/arm/marvell/mvsocreg.h P src/sys/arch/arm/nvidia/tegra_car.c P src/sys/arch/arm/nvidia/tegra_carreg.h P src/sys/arch/evbarm/marvell/marvell_machdep.c P src/sys/dev/pci/hifn7751.c P src/sys/kern/subr_disk.c P src/sys/nfs/nfs_vnops.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Fri May 15 03:39:29 2015 SUP Scan for current completed at Fri May 15 03:43:35 2015 SUP Scan for mirror starting at Fri May 15 03:43:35 2015 SUP Scan for mirror completed at Fri May 15 04:09:22 2015 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 47601050 May 15 04:27 ls-lRA.gz
Re: atf tests for devicemapper / dm ?
Hi, I can do some support if necessary but I'm afraid that no hacking in time soon. On Thu, May 14, 2015 at 4:13 AM, Paul Goyette p...@vps1.whooppee.com wrote: It looks there was a beginning of some regression tests for the dm(4) device, but they are currently disabled. It's not clear why they're disabled, although a comment within the test-body implies that it might be due to a need for multiple disk devices. ISTM that we could easily use vnd(4) pseudo devices to hostm the dm(4) linear/stripe members. Is there anyone around who is sufficiently fluent with dm(4) who could work on getting these tests finished and working? - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | - -- Regards. Adam
