daily CVS update output

2018-10-30 Thread NetBSD source update


Updating src tree:
P src/distrib/i386/installimage/Makefile
P src/external/bsd/top/dist/machine/m_netbsd.c
P src/libexec/rpc.rstatd/rstat_proc.c
P src/sbin/dmesg/dmesg.8
P src/sbin/dmesg/dmesg.c
P src/sbin/sysctl/sysctl.c
P src/share/man/man7/sysctl.7
P src/share/man/man9/time_second.9
P src/sys/arch/acorn32/stand/boot32/boot32.c
P src/sys/arch/arm/acpi/acpi_platform.c
P src/sys/arch/arm/altera/cycv_platform.c
P src/sys/arch/arm/arm/disassem.c
P src/sys/arch/arm/broadcom/bcm283x_platform.c
P src/sys/arch/arm/cavium/thunderx_platform.c
P src/sys/arch/arm/cortex/gic_v2m.c
P src/sys/arch/arm/cortex/gtmr.c
P src/sys/arch/arm/fdt/arm_fdtvar.h
P src/sys/arch/arm/nvidia/tegra_platform.c
P src/sys/arch/arm/rockchip/rk_platform.c
P src/sys/arch/arm/samsung/exynos_platform.c
P src/sys/arch/arm/sunxi/sunxi_platform.c
P src/sys/arch/arm/ti/ti_platform.c
P src/sys/arch/arm/vexpress/vexpress_platform.c
P src/sys/arch/arm/virt/virt_platform.c
P src/sys/arch/evbarm/conf/GENERIC
P src/sys/arch/evbarm/conf/files.fdt
P src/sys/arch/evbarm/conf/mk.generic
P src/sys/arch/evbarm/fdt/fdt_machdep.c
U src/sys/arch/evbarm/fdt/fdt_memory.c
U src/sys/arch/evbarm/fdt/fdt_memory.h
P src/sys/compat/common/kern_time_30.c
P src/sys/compat/common/kern_time_50.c
P src/sys/compat/netbsd32/netbsd32_time.c
P src/sys/kern/init_main.c
P src/sys/net/if.c
P src/sys/net/route.c
P src/sys/net/route.h
P src/sys/netinet/if_arp.c
P src/sys/netinet6/in6.c
P src/sys/netinet6/nd6.c
P src/usr.bin/w/w.c
P src/usr.sbin/rwhod/rwhod.c

Updating xsrc tree:


Killing core files:



Updating release-7 src tree (netbsd-7):
P common/include/prop/prop_array.h
P common/include/prop/prop_dictionary.h
P common/lib/libprop/prop_copyin_ioctl.9
P common/lib/libprop/prop_kern.c
P distrib/sgimips/instkernel/Makefile
P doc/3RDPARTY
U doc/CHANGES-7.3
P external/public-domain/tz/dist/CONTRIBUTING
P external/public-domain/tz/dist/Makefile
P external/public-domain/tz/dist/NEWS
P external/public-domain/tz/dist/README
U external/public-domain/tz/dist/TZDATA_VERSION
P external/public-domain/tz/dist/africa
P external/public-domain/tz/dist/antarctica
P external/public-domain/tz/dist/asia
P external/public-domain/tz/dist/australasia
P external/public-domain/tz/dist/backward
P external/public-domain/tz/dist/backzone
P external/public-domain/tz/dist/etcetera
P external/public-domain/tz/dist/europe
P external/public-domain/tz/dist/factory
P external/public-domain/tz/dist/leap-seconds.list
P external/public-domain/tz/dist/leapseconds
P external/public-domain/tz/dist/leapseconds.awk
P external/public-domain/tz/dist/northamerica
P external/public-domain/tz/dist/pacificnew
P external/public-domain/tz/dist/southamerica
P external/public-domain/tz/dist/systemv
P external/public-domain/tz/dist/theory.html
U external/public-domain/tz/dist/version
P external/public-domain/tz/dist/yearistype.sh
P external/public-domain/tz/dist/ziguard.awk
P external/public-domain/tz/dist/zishrink.awk
P external/public-domain/tz/dist/zone.tab
P external/public-domain/tz/dist/zone1970.tab
P external/public-domain/tz/dist/zoneinfo2tdf.pl
P sys/arch/pmax/pmax/dec_3min.c
P sys/arch/sgimips/conf/INSTALL32_IP2x
P sys/arch/sgimips/stand/boot/Makefile
P sys/dev/hpc/hpckbd.c
P sys/dev/pci/if_wm.c
P sys/net/npf/npf_ctl.c
P usr.bin/find/function.c
P usr.bin/systat/main.c
P usr.sbin/sysinst/arch/sgimips/md.c

Updating release-7 xsrc tree (netbsd-7):



Updating release-8 src tree (netbsd-8):
U doc/CHANGES-8.1
P sys/dev/pci/if_wm.c
P sys/dev/pci/pci_subr.c
P sys/dev/pci/pcireg.h

Updating release-8 xsrc tree (netbsd-8):




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  52927793 Oct 31 03:09 ls-lRA.gz


Re: "dmesg -T" date doesn't match "date" output

2018-10-30 Thread Robert Elz
Date:Tue, 30 Oct 2018 12:31:02 -0700
From:Dennis Ferguson 
Message-ID:  

You might, or might not depending which lists you read, have noticed that
I was working on this about the same time you were sending this message.

  | Note that time_second(9) says boottime is “the system boot time” (in 
UTC,
  | implicitly) while uptime is “the time elapsed since boot”. I believe 
this
  | unambiguously defines boottime to be the (UTC) time when uptime was zero;
  | boottime is uptime’s epoch. This doesn’t mean that boottime needs to be
  | set when uptime is zero, it just means that when boottime is set it needs
  | to be set to (time(now) - uptime(now)) rather than just time(now). That it
  | is initialized to the latter is the bug.

Yes, I think we came to that conclusion, and that is what I changed.

  | It may be worth pointing out that the code in kern/kern_tc.c is written to
  | maintain the identity
  |
  | time = uptime + boottime
  |
  | at all times, except that it instead maintains a local version of boottime
  | in the local variable timebasebin.

I knew the intended relationship, and noticed that code, but as most of
kern_tc.c is black art to me, I thought I'd  just trust that all that was 
correct, and leave it all alone!

  | I suspect the easiest way to fix the bug would be to eliminate the
  | independent initialization and maintenance of the boottime variable in
  | init_main.c and kern_time.c in favor of adding a
  |
  |  bintime2timespec(&timebasebin, &boottime);
  |
  | after timebasebin is updated in kern_tc.c:tc_setclock(). The code that
  | manipulates boottime outside of kern_tc.c is actually a leftover vestige
  | of the clock support code prior to timecounters that probably should have
  | disappeared when the latter was implemented.

Makes sense, and if someone wants to do that, then by all means...  (For me
it was easied to simply correct the init of  boottime.)

  | As a quibble, the code in kern_todr.c:inittodr() could probably be improved

No comment on that one.   Almost all code can be improved.

  | so calling
  |
  | tc_setclock(filesystemtime + uptime(now) + maybe_a_fudge_factor)
  |
  | would produce a time(now) that is at least a few seconds closer to reality.

Yes, it would I think, so instead of being (say) 8 hours out, it will be 7 
hours, 59 
mins, and 54 seconds...Is that really worth the bother?

kre



Re: "dmesg -T" date doesn't match "date" output

2018-10-30 Thread Michael van Elst
dennis.c.fergu...@gmail.com (Dennis Ferguson) writes:

>It may be worth pointing out that the code in kern/kern_tc.c is written to
>maintain the identity

>time = uptime + boottime

>at all times, except that it instead maintains a local version of boottime
>in the local variable timebasebin.

That is a weird way to describe that it does not maintain that identity.


>would produce a time(now) that is at least a few seconds closer to reality.

But would be mostly useless.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."


Относительно освободившейся вакансии

2018-10-30 Thread Наталия
Здравствуйте!

Увидела Вакансию на сайте, мы смогли бы подобрать Вам несколько возможных 
кандидатов. Пожалуйста сообщите - актуально ли это сейчас для Вас?

И смогли бы Вы работать с нами как с кадровым агентством?

У нас - реально очень низкая комиссия. Мы Проводим самостоятельное тестирование 
кандидитов - как личностное, так и профессиональное.

Если принципиальный интерес у Вас есть - я смогу прислать наши тарифы и 
варианты по сотрудникам.

Еще напишите - какие вакансии у Вас сейчас актуальны - вполне возможно - мы 
сможем закрыть их все.

С уважением, Наталия.


Re: "dmesg -T" date doesn't match "date" output

2018-10-30 Thread Dennis Ferguson


> On Oct 29, 2018, at 17:21, Robert Elz  wrote:
> 
>  | We are talking about internal kernel data. If you need $uptime, you
>  | could expose it like $boottime.
> 
> We could, but deisigning a system where now - boottime != uptime is
> kind of weird, don't you think?   boottime is where it all starts, if boottime
> is X, and uptime is Y, then X + Y should be now.
> 
> None of that means that there can't be activity before boot time of
> course, we need to pick an epoch, (just like unix timestamps have
> 0 at 1 Jan 1970) and it should be something meaningful, with
> some practical reason to exist - but pick a point to call 0 does
> not mean earlier times don't exist.

Note that time_second(9) says boottime is “the system boot time” (in UTC,
implicitly) while uptime is “the time elapsed since boot”. I believe this
unambiguously defines boottime to be the (UTC) time when uptime was zero;
boottime is uptime’s epoch. This doesn’t mean that boottime needs to be
set when uptime is zero, it just means that when boottime is set it needs
to be set to (time(now) - uptime(now)) rather than just time(now). That it
is initialized to the latter is the bug.

It may be worth pointing out that the code in kern/kern_tc.c is written to
maintain the identity

time = uptime + boottime

at all times, except that it instead maintains a local version of boottime
in the local variable timebasebin. While it is hard to deduce by reading it
the precision timescale that is maintained in there is actually uptime; when
something wants time it reads uptime(now) and adds timebasebin to it (i.e.
uptime + boottime) to compute the time of day. timebasebin is essentially
a version of ‘boottime’ that is initialized and maintained correctly, the
time of day of the uptime epoch.

I suspect the easiest way to fix the bug would be to eliminate the
independent initialization and maintenance of the boottime variable in
init_main.c and kern_time.c in favor of adding a

 bintime2timespec(&timebasebin, &boottime);

after timebasebin is updated in kern_tc.c:tc_setclock(). The code that
manipulates boottime outside of kern_tc.c is actually a leftover vestige
of the clock support code prior to timecounters that probably should have
disappeared when the latter was implemented.

As a quibble, the code in kern_todr.c:inittodr() could probably be improved
a bit. If reading the todr is successful what is returned is about the best
estimate of time(now) that we have so calling tc_setclock() with this value
is appropriate. If it falls back to the file system time, however, we can
not only be sure that this isn’t time(now) but is in fact a time that
predates the uptime epoch, so calling

tc_setclock(filesystemtime + uptime(now) + maybe_a_fudge_factor)

would produce a time(now) that is at least a few seconds closer to reality.

Dennis

Re: Failure to build "current" emacs from pkgsrc on current

2018-10-30 Thread Riccardo Mottola

Hi Leonardo,

Leonardo Taccari wrote:

(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:


sorry for the confusion. I updated once again pkgsrc, rebuilt gtk... and 
now building of emacs completed!


So that issue is solved for me. Thanks.

Riccardo


Re: "dmesg -T" date doesn't match "date" output

2018-10-30 Thread Michael van Elst
k...@munnari.oz.au (Robert Elz) writes:

>We could, but deisigning a system where now - boottime != uptime is
>kind of weird, don't you think?   boottime is where it all starts, if boottime
>is X, and uptime is Y, then X + Y should be now.

Weird, but that's how the real world is, arbitrary and imprecise
like humans. Mathematical beauty is for the gods.


-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."