daily CVS update output
Updating src tree: P src/distrib/sets/lists/comp/mi P src/doc/3RDPARTY P src/doc/CHANGES P src/external/public-domain/tz/dist/NEWS U src/external/public-domain/tz/dist/TZDATA_VERSION P src/external/public-domain/tz/dist/africa P src/external/public-domain/tz/dist/europe P src/external/public-domain/tz/dist/northamerica P src/external/public-domain/tz/dist/theory.html U src/external/public-domain/tz/dist/version P src/external/public-domain/tz/dist/ziguard.awk P src/external/public-domain/tz/dist/zishrink.awk P src/lib/libc/time/NEWS P src/lib/libc/time/theory.html P src/lib/libc/time/tz-how-to.html P src/lib/libc/time/tz-link.html P src/lib/libc/time/tzfile.5 U src/lib/libc/time/version P src/lib/libc/time/zdump.8 P src/lib/libc/time/zic.8 P src/lib/libc/time/zic.c P src/sys/arch/amd64/amd64/asan.c P src/sys/arch/arm/include/arm32/vmparam.h P src/sys/dev/ic/wdc.c P src/sys/kern/subr_tftproot.c P src/sys/net/if_pppoe.c P src/sys/netipsec/ipsec.c P src/sys/netipsec/ipsec.h P src/sys/netipsec/ipsec_input.c P src/usr.bin/gzip/gzip.c P src/usr.bin/gzip/unlz.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 52936563 Oct 28 03:03 ls-lRA.gz
Re: "dmesg -T" date doesn't match "date" output
On Sunday 2018-10-28 13:16 +1100, Geoff Wing output: :Hi, :I'm running the same -current build on two x64 machines. One is a VM :and the other is bare-metal. I'm rebuilding in case something funny :happened in the build and noone else can reproduce anything similar. : :The ntpdate in /var/run/rc.log said it updated 0.3 secs and both machines :had time differences of 5-6 secs between dmesg / date commands. I suspect it may be that boottime is being set late. My dmesg has: [ 6.730563] root on sd0a dumps on sd0b [ 6.730563] root file system type: ffs [ 6.730563] kern.module.path=/stand/amd64/8.99.25/modules >From my quick look, sys/kern/init_main.c:666 initialises boottime after mounting the root file system, so "dmesg -T" is using a bad value. Regards, Geoff
Re: "dmesg -T" date doesn't match "date" output
On Sunday 2018-10-28 08:32 +0700, Robert Elz output: :I don't suppose that your ToD clock is 6 seconds incorrect, and :ntpdate run from /etc/rc is fixing that (but the ToD clock isn't being :updated) ? : :if it is not that, then you're right, something weird is happening. Hi, I'm running the same -current build on two x64 machines. One is a VM and the other is bare-metal. I'm rebuilding in case something funny happened in the build and noone else can reproduce anything similar. The ntpdate in /var/run/rc.log said it updated 0.3 secs and both machines had time differences of 5-6 secs between dmesg / date commands. Regards, Geoff
Re: "dmesg -T" date doesn't match "date" output
Date:Sun, 28 Oct 2018 12:01:55 +1100 From:Geoff Wing Message-ID: <20181028010155.ga1...@primenet.com.au> | Ah, I just rebooted it so that's 1 min and 13 seconds, | not 1 month and 13 seconds. I should have known that, since I'm responsible for the current code that generates that format (it max's out at hours, nothing bigger, as they get ambiguous). I don't suppose that your ToD clock is 6 seconds incorrect, and ntpdate run from /etc/rc is fixing that (but the ToD clock isn't being updated) ? if it is not that, then you're right, something weird is happening. kre
Re: "dmesg -T" date doesn't match "date" output
On Sunday 2018-10-28 07:19 +0700, Robert Elz output: : | The dmesg time matches what appears in kern.boottime but I don't see a 5-6 : | second step in rc.log when ntpdate is run. :You wouldn't now. The system from which you showed that output has :been up for a month. During that month, either in one jump, or more :likely, continuously, I suspect that the time has been slowed from what :your system clock source would have generated, to match NTP time. : :So, while there has been a month and 13 seconds of clock ticks, the :actual time has actually advanced just a month and 7 seconds. : :Or that is what I'd assume - but I'm no expert on NetBSD timekeeping. Ah, I just rebooted it so that's 1 min and 13 seconds, not 1 month and 13 seconds.
Re: "dmesg -T" date doesn't match "date" output
Date:Sun, 28 Oct 2018 09:51:43 +1100 From:Geoff Wing Message-ID: <20181027225143.ga...@primenet.com.au> | The dmesg time matches what appears in kern.boottime but I don't see a 5-6 | second step in rc.log when ntpdate is run. You wouldn't now. The system from which you showed that output has been up for a month. During that month, either in one jump, or more likely, continuously, I suspect that the time has been slowed from what your system clock source would have generated, to match NTP time. So, while there has been a month and 13 seconds of clock ticks, the actual time has actually advanced just a month and 7 seconds. Or that is what I'd assume - but I'm no expert on NetBSD timekeeping. kre
Re: "dmesg -T" date doesn't match "date" output
On Saturday 2018-10-27 19:03 +0700, Robert Elz output: :Date:Sat, 27 Oct 2018 17:39:16 +1100 :From:Geoff Wing :Message-ID: <20181027063916.ga2...@primenet.com.au> : : | dates output by "dmesg -T" are not matching real time. Using a program : | to generate a segfault dmesg is showing times in the future: : :dmesg times come from "seconds since boot" which is what is actually :logged, added to boottime. The seconds since boot is, I believe, a monotonic :counter which counts at timer rate, unadjusted for clock errors. : :I'd assume you're running NTP or similar to sync your clock, and that it :is constantly slowing down your timer - apparently by 6 seconds since :boot, which suggests that either your clock is wildly inaccurate, or that :your system has been up for a fairly lengthy time (at least a week probably). : :What does dmesg say without the -T, or perhaps using -TT : :The dmesg man page should perhaps explain all of this a little better. I've tried on two -current amd64 machines and both were showing similar issues. The dmesg time matches what appears in kern.boottime but I don't see a 5-6 second step in rc.log when ntpdate is run. Something fishy is going on. # ./segfault; date; dmesg -T | tail -1; dmesg -TT | tail -1 [1]871 segmentation fault ./segfault Sun Oct 28 09:37:49 AEDT 2018 [Sun Oct 28 09:37:55 AEDT 2018] pid 871 (segfault), uid 0: exited on signal 11 (core not dumped, err = 1) [PT1M13.006S] pid 871 (segfault), uid 0: exited on signal 11 (core not dumped, err = 1) # sysctl kern.boottime kern.boottime = Sun Oct 28 09:36:42 2018 # ntpq -p remote refid st t when poll reach delay offset jitter == XX 3 s3 12870.588 -4.308 3.546 XX 3 s7 12830.228 -3.728 0.066 XX 4 s 62 12870.100 -4.151 2.945 +XX 3 u 28 6430.812 -2.945 2.411 *XX 3 u 80 1281 12.870 -6.306 0.032 ( from /var/run/rc.log ) [running /etc/rc.d/ntpdate] Setting date via ntp. 28 Oct 09:37:01 ntpdate[229]: step time server XX offset 0.304666 sec Regards, Geoff
Re: Failure to build "current" emacs from pkgsrc on current
Hello Greg, Andreas and Riccardo,
Leonardo Taccari writes:
> [...]
> I have just added it to buildlink3.mk, please let me know if that
> fixes the problem you have reported! (just a `make replace' in
> emacs or any other problematic package should be enough to test
> that)
> [...]
(More information was appended to PR pkg/53688 opened by Andreas
but I will try to summarize all possible details here too for
completeness, TLDR; emacs25-25.3nb10 and emacs26-26.1nb3 should
now works properly.)
Despite the buildlink3.mk change was needed it didn't solve the
problem originally reported by Riccardo.
Maya suggested to pass `-Wl,--verbose' to get more details about
the linking failures (by adding them to src/Makefile in `temacs$(EXEEXT):'
target) and indeed this pointed out the following:
libepoxy.so.0 needed by
.../pkgsrc/editors/emacs25/work/.buildlink/lib/libgtk-3.so
found libepoxy.so.0 at /usr/X11R7/lib/libepoxy.so.0
Inspecting the corresponding lines in work.log I have noticed that there
were extra and early `-Wl,-rpath,/usr/X11R7/lib' flags.
The emacs configure script was injecting them on NetBSD and OpenBSD.
The patch applied just comment out that part that is handled by
pkgsrc in configure{,.ac}.
Sorry again for breaking them and please let me know if you find
any regression.
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2018.10.27.11.39.12 skrll src/usr.bin/gzip/gzip.c,v 1.116 2018.10.27.11.52.26 kre src/usr.bin/gzip/unlz.c,v 1.2 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.10.html#2018.10.27.11.52.26
Re: Automated report: NetBSD-current/i386 build failure
On Oct 27, 12:59pm, g...@gson.org (Andreas Gustafsson) wrote:
-- Subject: Re: Automated report: NetBSD-current/i386 build failure
| The i386 build is still failing in gzip:
|
| /tmp/bracket/build/2018.10.27.07.24.58-i386/src/usr.bin/gzip/unlz.c:580:21:
error: format '%td' expects argument of type 'ptrdiff_t', but argument 3 has
type '__off_t {aka long long int}' [-Werror=format=]
|
kre fixed it and I removed it (it was debugging).
christos
Re: Failure to build "current" emacs from pkgsrc on current
Hello Andreas, Greg and Riccardo, Andreas Gustafsson writes: > Greg, Riccardo, > > Please disregard the parts of my earlier mail that pertained to > tests run under NetBSD-current. I had missed the fact that > ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz is only > regenerated weekly, and accidentally tested using a pkgsrc.tar.gz > that was five days old and still had gtk+-3.22.30.nb3 rather than > gtk+-3.24.1. > > I will rerun my test and report the new results in a pkgsrc PR, > since current-users is not really the right forum for this. > [...] I am probably responsable for breaking it when updating it to 3.24.1, sorry! gtk+-3.24.1 needs libepoxy>=1.4 and that requirements was specified via BUILDLINK_API_DEPENDS.libepoxy in pkgsrc/x11/gtk3/Makefile. However, I have accidentally forgotten to add t in pkgsrc/x11/gtk3/buildlink3.mk too. I have just added it to buildlink3.mk, please let me know if that fixes the problem you have reported! (just a `make replace' in emacs or any other problematic package should be enough to test that) Sorry again and thank you for your patience and analysis of the problem!
Re: "dmesg -T" date doesn't match "date" output
Date:Sat, 27 Oct 2018 17:39:16 +1100 From:Geoff Wing Message-ID: <20181027063916.ga2...@primenet.com.au> | dates output by "dmesg -T" are not matching real time. Using a program | to generate a segfault dmesg is showing times in the future: dmesg times come from "seconds since boot" which is what is actually logged, added to boottime. The seconds since boot is, I believe, a monotonic counter which counts at timer rate, unadjusted for clock errors. I'd assume you're running NTP or similar to sync your clock, and that it is constantly slowing down your timer - apparently by 6 seconds since boot, which suggests that either your clock is wildly inaccurate, or that your system has been up for a fairly lengthy time (at least a week probably). What does dmesg say without the -T, or perhaps using -TT The dmesg man page should perhaps explain all of this a little better. kre
Re: Automated report: NetBSD-current/i386 build failure
The i386 build is still failing in gzip:
/tmp/bracket/build/2018.10.27.07.24.58-i386/src/usr.bin/gzip/unlz.c:580:21:
error: format '%td' expects argument of type 'ptrdiff_t', but argument 3 has
type '__off_t {aka long long int}' [-Werror=format=]
--
Andreas Gustafsson, g...@gson.org
Re: Failure to build "current" emacs from pkgsrc on current
Greg, Riccardo, Please disregard the parts of my earlier mail that pertained to tests run under NetBSD-current. I had missed the fact that ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz is only regenerated weekly, and accidentally tested using a pkgsrc.tar.gz that was five days old and still had gtk+-3.22.30.nb3 rather than gtk+-3.24.1. I will rerun my test and report the new results in a pkgsrc PR, since current-users is not really the right forum for this. -- Andreas Gustafsson, g...@gson.org
"dmesg -T" date doesn't match "date" output
Hi, dates output by "dmesg -T" are not matching real time. Using a program to generate a segfault dmesg is showing times in the future: # sysctl -w kern.logsigexit=1 kern.logsigexit: 0 -> 1 # ./segfault; date [1]18445 segmentation fault ./segfault Sat Oct 27 17:33:56 AEDT 2018 # dmesg -T | tail -1 [Sat Oct 27 17:34:02 AEDT 2018] pid 18445 (segfault), uid 0: exited on signal 11 (core not dumped, err = 13)
