daily CVS update output
Updating src tree: P src/bin/cp/Makefile P src/bin/cp/cp.c P src/bin/cp/utils.c P src/bin/ls/Makefile P src/bin/ls/print.c P src/distrib/sets/lists/comp/md.sparc P src/distrib/sets/lists/comp/md.sparc64 P src/distrib/sets/lists/debug/md.amd64 P src/distrib/sets/lists/tests/md.amd64 P src/distrib/sets/lists/tests/mi P src/distrib/sets/lists/tests/module.mi P src/sys/arch/amd64/amd64/spl.S P src/sys/arch/amd64/amd64/vector.S U src/sys/arch/arm/dts/rk3399-crypto.dtsi P src/sys/arch/arm/dts/rk3399-pinebook-pro.dts P src/sys/arch/arm/dts/rk3399-rockpro64.dts P src/sys/arch/arm/rockchip/files.rockchip P src/sys/arch/arm/rockchip/rk3399_cru.c U src/sys/arch/arm/rockchip/rk_v1crypto.c U src/sys/arch/arm/rockchip/rk_v1crypto.h P src/sys/arch/evbarm/conf/GENERIC64 P src/sys/arch/i386/i386/spl.S P src/sys/arch/i386/i386/vector.S P src/sys/arch/sparc/include/Makefile P src/sys/arch/sparc/include/types.h P src/sys/arch/x86/x86/hyperv.c P src/sys/dev/acpi/thinkpad_acpi.c P src/sys/dev/ic/dwc_gmac.c P src/sys/dev/ic/dwc_gmac_reg.h P src/sys/dev/pci/hifn7751.c P src/sys/dev/usb/ehci.c P src/sys/fs/tmpfs/tmpfs.h P src/sys/fs/tmpfs/tmpfs_subr.c P src/sys/fs/tmpfs/tmpfs_vnops.c P src/sys/kern/kern_softint.c P src/sys/kern/vfs_trans.c P src/sys/miscfs/genfs/genfs_io.c P src/sys/nfs/nfs_bio.c P src/sys/sys/intr.h P src/sys/uvm/uvm.h P src/sys/uvm/uvm_amap.c P src/sys/uvm/uvm_aobj.c P src/sys/uvm/uvm_fault.c P src/sys/uvm/uvm_loan.c P src/sys/uvm/uvm_page.c P src/sys/uvm/uvm_page.h P src/sys/uvm/uvm_pager.h P src/sys/uvm/uvm_pdpolicy.h P src/sys/uvm/uvm_pdpolicy_clock.c P src/sys/uvm/uvm_pdpolicy_clockpro.c P src/tests/Makefile.inc P src/usr.bin/make/unit-tests/Makefile P src/usr.bin/make/unit-tests/dollar.exp P src/usr.bin/make/unit-tests/dollar.mk U src/usr.bin/make/unit-tests/include-main.exp U src/usr.bin/make/unit-tests/include-main.mk U src/usr.bin/make/unit-tests/include-sub.mk U src/usr.bin/make/unit-tests/include-subsub.mk P src/usr.bin/rump_allserver/Makefile P src/usr.sbin/puffs/Makefile.inc Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38381204 May 18 03:10 ls-lRA.gz
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: atf/atf-c/detail/fs_test:mkdtemp_err atf/atf-c/detail/fs_test:mkstemp_err bin/cp/t_cp:dir_to_dir fs/vfs/t_unpriv:ext2fs_owner fs/vfs/t_unpriv:ext2fs_times fs/vfs/t_unpriv:ffs_owner fs/vfs/t_unpriv:ffs_times fs/vfs/t_unpriv:ffslog_owner fs/vfs/t_unpriv:ffslog_times fs/vfs/t_unpriv:lfs_owner fs/vfs/t_unpriv:lfs_times fs/vfs/t_unpriv:msdosfs_times fs/vfs/t_unpriv:nfs_owner fs/vfs/t_unpriv:nfs_times fs/vfs/t_unpriv:p2k_ffs_owner fs/vfs/t_unpriv:p2k_ffs_times fs/vfs/t_unpriv:rumpfs_owner fs/vfs/t_unpriv:rumpfs_times fs/vfs/t_unpriv:sysvbfs_owner fs/vfs/t_unpriv:sysvbfs_times fs/vfs/t_unpriv:tmpfs_owner fs/vfs/t_unpriv:tmpfs_times fs/vfs/t_unpriv:udf_owner fs/vfs/t_unpriv:udf_times fs/vfs/t_unpriv:v7fs_owner fs/vfs/t_unpriv:v7fs_times lib/libc/c063/t_o_search:o_search_perm1 lib/libc/c063/t_o_search:o_search_perm2 lib/libc/sys/t_access:access_access lib/librumphijack/t_tcpip:nfs The above tests failed in each of the last 4 test runs, and passed in at least 26 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.05.16.17.37.28 ad src/sys/arch/sparc/include/cpu.h,v 1.107 2020.05.16.17.42.06 hannken src/sys/kern/subr_kcov.c,v 1.15 2020.05.16.17.52.42 ad src/sys/arch/sparc/include/cpu.h,v 1.108 2020.05.16.17.52.42 ad src/sys/arch/sparc/include/types.h,v 1.67 2020.05.16.18.31.45 christos src/bin/Makefile,v 1.23 2020.05.16.18.31.45 christos src/bin/cp/cp.c,v 1.60 2020.05.16.18.31.45 christos src/bin/cp/extern.h,v 1.18 2020.05.16.18.31.45 christos src/bin/cp/utils.c,v 1.48 2020.05.16.18.31.45 christos src/bin/getfacl/Makefile,v 1.1 2020.05.16.18.31.45 christos src/bin/getfacl/getfacl.1,v 1.1 2020.05.16.18.31.45 christos src/bin/getfacl/getfacl.c,v 1.1 2020.05.16.18.31.45 christos src/bin/ls/ls.1,v 1.81 2020.05.16.18.31.45 christos src/bin/ls/print.c,v 1.56 2020.05.16.18.31.45 christos src/bin/setfacl/Makefile,v 1.1 2020.05.16.18.31.45 christos src/bin/setfacl/file.c,v 1.1 2020.05.16.18.31.45 christos src/bin/setfacl/mask.c,v 1.1 2020.05.16.18.31.45 christos src/bin/setfacl/merge.c,v 1.1 2020.05.16.18.31.45 christos src/bin/setfacl/remove.c,v 1.1 2020.05.16.18.31.45 christos src/bin/setfacl/setfacl.1,v 1.1 2020.05.16.18.31.45 christos src/bin/setfacl/setfacl.c,v 1.1 2020.05.16.18.31.45 christos src/bin/setfacl/setfacl.h,v 1.1 2020.05.16.18.31.45 christos src/bin/setfacl/util.c,v 1.1 2020.05.16.18.31.45 christos src/distrib/sets/lists/base/mi,v 1.1243 2020.05.16.18.31.45 christos src/distrib/sets/lists/comp/mi,v 1.2327 2020.05.16.18.31.46 christos src/distrib/sets/lists/debug/mi,v 1.311 2020.05.16.18.31.46 christos src/distrib/sets/lists/man/mi,v 1.1689 2020.05.16.18.31.46 christos src/external/bsd/libarchive/include/config_netbsd.h,v 1.12 2020.05.16.18.31.46 christos src/external/bsd/libarchive/lib/libarchive/Makefile,v 1.12 2020.05.16.18.31.46 christos src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ctldir.c,v 1.12 2020.05.16.18.31.46 christos src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c,v 1.67 2020.05.16.18.31.46 christos src/external/cddl/osnet/sys/kern/policy.c,v 1.8 2020.05.16.18.31.46 christos src/external/cddl/osnet/sys/sys/policy.h,v 1.9 2020.05.16.18.31.47 christos src/include/mntopts.h,v 1.19 2020.05.16.18.31.47 christos src/include/unistd.h,v 1.158 2020.05.16.18.31.47 christos src/lib/libc/Makefile,v 1.173 2020.05.16.18.31.47 christos src/lib/libc/posix1e/Makefile.inc,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_add_flag_np.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_add_perm.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_branding.c,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_calc_mask.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_calc_mask.c,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_clear_flags_np.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_clear_perms.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_compat.c,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_copy.c,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_copy_entry.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_create_entry.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_delete.3,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_delete.c,v 1.1 2020.05.16.18.31.47 christos src/lib/libc/posix1e/acl_delete_entry.3,v 1.1 2020.05.16.18.31.47 christos
amd64 apu dmesg
Hi guys, would it help if I posted my dmesg? use NetBSD 9.99.63 dmesg.rd Description: chemical/mdl-rdfile
Re: github.com/NetBSD/src 5 days old?
On Thu, 14 May 2020 at 09:23, Hauke Fath wrote: > [re-directing to tech-repository, which was created precisely to keep > debates like this one off the other lists...] > > On Thu, 14 May 2020 14:47:02 +0200, Jens Rehsack wrote: > > I doubt that you'll find a modern solution running fine on any 4M > computer. > > Network filesystems, cross compilers etc. where invented to support > machines > > which can't provide all required resources for a job on their own. > > Unfortunately, the VCS equivalent to your list would be a client > connecting to a beefy local DVCS instance, which to the best of my > knowledge has not been invented, yet. > Actually, it has already been invented. GitHub has links to download the checkout as a zip archive from any branch. E.g., https://github.com/NetBSD/src/archive/netbsd-9.zip has the checkout from `netbsd-9`. I've just tried how it works, and am getting 5MB/s on my 12.6MB/s connection through the WiFi in the office, so, it seems to be working good enough. I believe they archive it on the go, as a stream, because there's no file size upfront when you first download it; I've tried downloading it a second time right after completing the first one, and I did get the size then (Length: 548765520 (523M) [application/zip]), so, they are smart enough to cache it at least for some time. Of course, the biggest issue is that there's no way to ignore any specific parts of the tree, so, you're stuck with downloading a 0.5GB archive of a 2.4GB checkout. I'm still of the opinion that it might be a good idea to split the `src` repository into several sub-repositories like syssrc, gnusrc and src, as per http://mail-index.netbsd.org/tech-repository/2020/02/21/msg000698.html. Or maybe at least provide such a setup as an option, especially to just get the kernel? Cheers, Constantine.
Re: How long to build from source?
Hi, nottobay wrote: I have a 5 year old a8 laptop. How can I figure out how long compiling the current source will take? If you gave 2GB of RAM it should be fine, enable the cores you have for building. 3 or 4GB make a much better impact than SSD. I did not find SSD have a big impact compiling (and I am also a Gentoo user!), however they make using CVS/SVN/GIT operations faster. Actually, there are things that sometimes are slower on certain SSD. The biggest impact is to disable LLVM! I can do it for my intel card... and it reduced build times in terms of days back to something manageable, which is about a day Releng offers you readby build though and it is useful to compile perhaps only your kernel, which should on your machine take less than one hour (my single core Turion AMD64 takes 50 minutes) Riccardo
Re: lang/mono6 fails build under -current
On Sun, May 17, 2020 at 09:58:49AM +0100, Chavdar Ivanov wrote:
> On Fri, 15 May 2020 at 22:44, wrote:
> > I am failing to reproduce it on 9.99.61. Any other guesses for what
> > might be different on your setup?
>
> No idea. It is a laptop with i7-3820QM CPU and 20GB memory, following
> -current, both the OS and pkgsrc, with many pkg_rolling-replace under
> its belt. Perhaps it is time to reinstall it...
>
> I spun a new VM (XCP-NG pvhvm domU, with just 4 virtual CPUs and 2GB
> memory), extracted and updated pkgsrc as of yesterday, mono6 built
> fine and I was then able to install the package on the troubled
> system:
>
> $ mono --version
> Mono JIT compiler version 6.8.0.105 (tarball Sat May 16 22:47:11 BST 2020)
> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
> www.mono-project.com
> TLS: __thread
> SIGSEGV: normal
> Notification: kqueue
> Architecture: amd64
> Disabled: none
> Misc: softdebug
> Interpreter: yes
> LLVM: supported, not enabled.
> Suspend: preemptive
> GC:sgen (concurrent by default)
>
> The thing is, while pkg_rolling-replace does simplify the gradual
> updates of packages, there are situations it can't deal with; e.g. 4-5
> days ago I updated and ran pkg_rolling-replace, which completed rather
> well, with only about 10 packages failing due to being obsoleted etc.;
> all the tex packages I have installed upgraded without a problem.
> Yesterday I did another update, this time rolling-replace rendered
> hundreds of failed upgrades among the tex packages. The reason (one of
> the reasons) turned out to be a new version of kpathsea - 6.3.2 -
> which now depends on mktexlsr package; this one has been split from
> kpathsea and contains a file - well, mktexlsr - which is also part of
> kpathsea-6.3.1; so mktexlsr can't be installed over kpathsea, and
> kpathsea can't be upgraded as mktexlsr is missing... And this was not
> the only problem.
As an unrelated but interesting side note, Mono is the only package I've
seen make a Xen-specific optimization.
mono_x86_emit_tls_get (guint8* code, int dreg, int tls_offset)
...
if (optimize_for_xen) {
x86_prefix (code, X86_GS_PREFIX);
x86_mov_reg_mem (code, dreg, 0, 4);
x86_mov_reg_membase (code, dreg, dreg, tls_offset, 4);
} else {
x86_prefix (code, X86_GS_PREFIX);
x86_mov_reg_mem (code, dreg, tls_offset, 4);
}
Re: lang/mono6 fails build under -current
On Fri, 15 May 2020 at 22:44, wrote: > > On Tue, May 12, 2020 at 02:41:19PM +0100, Chavdar Ivanov wrote: > > On Tue, 12 May 2020 at 14:03, wrote: > > > > > > On Mon, May 11, 2020 at 05:25:03PM +0100, Chavdar Ivanov wrote: > > > > Has anybody been able to build lang/mono6 under reasonably recent > > > > -current? I keep getting exciting crashes in various places, seem not > > > > to repeat, e.g. > > > > > > > > > I can build it. > > > > > > Setup: > > > userland: 9.99.51 (early March) > > > kernel: 9.99.59 (early May) > > > > Userland and kernel from yesterday, 11th of May > > > > > > GCC 8.4.0 > > > > Ditto > > > > > binutils 2.31.1 > > > > As far as I can see it, on this version of the system it is 2.34: > > > > nm -V > > GNU nm (NetBSD Binutils nb1) 2.34. > > > > I never run kernel and userland from different versions, as I use > > sysbuild and sysupgrade. > > I am failing to reproduce it on 9.99.61. Any other guesses for what > might be different on your setup? No idea. It is a laptop with i7-3820QM CPU and 20GB memory, following -current, both the OS and pkgsrc, with many pkg_rolling-replace under its belt. Perhaps it is time to reinstall it... I spun a new VM (XCP-NG pvhvm domU, with just 4 virtual CPUs and 2GB memory), extracted and updated pkgsrc as of yesterday, mono6 built fine and I was then able to install the package on the troubled system: $ mono --version Mono JIT compiler version 6.8.0.105 (tarball Sat May 16 22:47:11 BST 2020) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: normal Notification: kqueue Architecture: amd64 Disabled: none Misc: softdebug Interpreter: yes LLVM: supported, not enabled. Suspend: preemptive GC:sgen (concurrent by default) The thing is, while pkg_rolling-replace does simplify the gradual updates of packages, there are situations it can't deal with; e.g. 4-5 days ago I updated and ran pkg_rolling-replace, which completed rather well, with only about 10 packages failing due to being obsoleted etc.; all the tex packages I have installed upgraded without a problem. Yesterday I did another update, this time rolling-replace rendered hundreds of failed upgrades among the tex packages. The reason (one of the reasons) turned out to be a new version of kpathsea - 6.3.2 - which now depends on mktexlsr package; this one has been split from kpathsea and contains a file - well, mktexlsr - which is also part of kpathsea-6.3.1; so mktexlsr can't be installed over kpathsea, and kpathsea can't be upgraded as mktexlsr is missing... And this was not the only problem. --
