Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-03 Thread Frank Kardel
Hi Roy ! That looks more semantics (the ones I know of - dynamic interface scanning is one of my NTPd parts) preserving now. So far I see no other issues from the pitfalls I know of. Lets hope our kernel and other SO_RERRORS systems miss any interface scan worthy events. Frank On

Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-03 Thread Roy Marples
On 02/01/2021 23:33, Frank Kardel wrote: Also the behavior now fully relies in the routing message functionality which can be disabled on serious procession errors - at that point the code robustness relies on the periodic re-scanning - so I am not sure whether the periodic re-scanning

Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-03 Thread Roy Marples
On 02/01/2021 23:33, Frank Kardel wrote: Hi Roy ! This may look like a better solution from the interface tracking side. People have requested being able to disable dynamic interface updates completely. This was implemented via the -U 0. ... This patch seems (by visual inspection) to

Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-02 Thread Frank Kardel
Hi Roy ! This may look like a better solution from the interface tracking side. People have requested being able to disable dynamic interface updates completely. This was implemented via the -U 0. See man ntpd: ... −U number, −−updateinterval=number interval in

Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-02 Thread Roy Marples
On 02/01/2021 17:23, Roy Marples wrote: That's a good point, with this we can now remove that forced sync on a timer approach. Does this look ok? Better patch: diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c --- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33 2021

Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-02 Thread Roy Marples
Hi Frank On 02/01/2021 09:55, Frank Kardel wrote: I doubt that the explicit draining is helpful here as it already happens I was aware of that. I was just trying to avoid excess timer interface timeouts if we don't get around to reading the next message in UPDATE_GRACE time. Let's see what

Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-02 Thread Frank Kardel
Hi Roy ! I doubt that the explicit draining is helpful here as it already happens in the outer loop processing any routing socket input. All that is happening in the routing messages processing path is to call timer_interfacetimeout(current_time + UPDATE_GRACE) and this is robust for

Re: CVS commit: src/external/bsd/unbound/lib/libunbound

2021-01-01 Thread Robert Elz
Date:Fri, 1 Jan 2021 20:38:36 + From:"Roy Marples" Message-ID: <20210101203836.2cadcf...@cvs.netbsd.org> | Modified Files: | src/external/bsd/unbound/lib/libunbound: Makefile | | Log Message: | libunbound: Now we use libevent, don't build mini_event

Re: CVS commit: src/external/gpl2/diffutils/dist/src

2020-12-12 Thread Joerg Sonnenberger
On Sun, Dec 13, 2020 at 12:04:40AM +, Roy Marples wrote: > Module Name: src > Committed By: roy > Date: Sun Dec 13 00:04:40 UTC 2020 > > Modified Files: > src/external/gpl2/diffutils/dist/src: util.c > > Log Message: > diffutils: execl requires a NULL sentinel Strictly

Re: CVS commit: src/external/gpl3/gdb/dist/gdb

2020-12-10 Thread Kamil Rytarowski
On 10.12.2020 08:14, Rin Okuyama wrote: > Module Name: src > Committed By: rin > Date: Thu Dec 10 07:14:58 UTC 2020 > > Modified Files: > src/external/gpl3/gdb/dist/gdb: nbsd-nat.c > > Log Message: > Fix arm, for which PT_STEP is defined but unimplemented. > > XXX > Stop exposing

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

2020-11-29 Thread Yorick Hardy
On 2020-11-28, Yorick Hardy wrote: > Module Name: src > Committed By: yhardy > Date: Sat Nov 28 22:53:06 UTC 2020 > > Modified Files: > src/external/cddl/osnet/dist/uts/common/fs/zfs: vdev_disk.c > > Log Message: > Use vn_close to release the vnodes in the error handling blocks,

Re: CVS commit: src/external/bsd/tmux

2020-11-01 Thread Christos Zoulas
I've asked. Best, christos > On Nov 1, 2020, at 11:19 AM, Kimmo Suominen wrote: > >> Log Message: >> CHANGED FROM 3.1b TO 3.1c >> >> * Do not write after the end of the array and overwrite the stack when >> colon-separated SGR sequences contain empty arguments. > > Pullup to -9 and -8 for

Re: CVS commit: src/external/bsd/tmux

2020-11-01 Thread Kimmo Suominen
> Log Message: > CHANGED FROM 3.1b TO 3.1c > > * Do not write after the end of the array and overwrite the stack when > colon-separated SGR sequences contain empty arguments. Pullup to -9 and -8 for security fix? https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-20 Thread Joerg Sonnenberger
On Wed, Oct 21, 2020 at 08:58:36AM +0900, Rin Okuyama wrote: > I'm also one who feels hesitate to import Linux'ism into our basic > components. However, for this problem in particular, I still think > it is not a good choice to keep NetBSD support in driver-aarch64.c: > > (a) Our sysctl(3)-based

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-20 Thread Rin Okuyama
Hi, (tech-toolchain@ added to cc) On 2020/10/16 1:49, Kamil Rytarowski wrote: On 15.10.2020 17:14, Rin Okuyama wrote: On 2020/10/15 16:12, matthew green wrote: Martin Husemann writes: On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: you could try reverting most of our changes

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-16 Thread Robert Elz
Date:Fri, 16 Oct 2020 04:07:31 + From:"Thomas Mueller" Message-ID: <20201016052422.e063084...@mail.netbsd.org> | Should I add ,linux to the end of the procfs line? You can, but it isn't needed these days -- I used to mount procfs twice, once without the linux

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread Thomas Mueller
Excerpt from Rin Okuyama: > Nowadays, -o linux is turned on by default (unless nolinux is > specified explicitly). Still, native apps probably should not > depend on it. > This needs MI changes to procfs, not MD to aarch64. Should we > enable /proc/cpuinfo unconditionally? My NetBSD

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread Kamil Rytarowski
On 15.10.2020 17:14, Rin Okuyama wrote: > On 2020/10/15 16:12, matthew green wrote: >> Martin Husemann writes: >>> On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: you could try reverting most of our changes to this file and making sure you run with /proc mounted -o linux. 

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread Rin Okuyama
On 2020/10/15 16:12, matthew green wrote: Martin Husemann writes: On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: you could try reverting most of our changes to this file and making sure you run with /proc mounted -o linux. ryo@ recently added additional /proc/cpuinfo support

re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread matthew green
Martin Husemann writes: > On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: > > you could try reverting most of our changes to this file and > > making sure you run with /proc mounted -o linux. ryo@ recently > > added additional /proc/cpuinfo support that should make this > > just

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread Martin Husemann
On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: > you could try reverting most of our changes to this file and > making sure you run with /proc mounted -o linux. ryo@ recently > added additional /proc/cpuinfo support that should make this > just work with the upstream version, but

re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-10-15 Thread matthew green
"Rin Okuyama" writes: > Module Name: src > Committed By: rin > Date: Tue Oct 13 07:12:00 UTC 2020 > > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/aarch64: driver-aarch64.c > > Log Message: > Reduce diff with upstream a bit. > No functional changes. you could try

Re: CVS commit: src/external/gpl3/gdb/dist/gdb

2020-10-14 Thread Christos Zoulas
Thanks for fixing it! christos signature.asc Description: Message signed with OpenPGP

Re: CVS commit: src/external/gpl3/gdb/dist/gdb

2020-10-14 Thread Kamil Rytarowski
On 13.10.2020 11:14, Leonardo Taccari wrote: > Hello Kamil, > > Kamil Rytarowski writes: >> Module Name: src >> Committed By:kamil >> Date:Tue Oct 6 23:14:47 UTC 2020 >> >> Modified Files: >> src/external/gpl3/gdb/dist/gdb: inf-ptrace.c nbsd-nat.c >> >> Log Message:

Re: CVS commit: src/external/gpl3/gdb/dist/gdb

2020-10-13 Thread Leonardo Taccari
Hello Kamil, Kamil Rytarowski writes: > Module Name: src > Committed By: kamil > Date: Tue Oct 6 23:14:47 UTC 2020 > > Modified Files: > src/external/gpl3/gdb/dist/gdb: inf-ptrace.c nbsd-nat.c > > Log Message: > Undo local patches > > They are no longer needed (and are wrong). >

Re: CVS commit: src/external/public-domain/tz/dist

2020-10-08 Thread Robert Elz
Date:Thu, 08 Oct 2020 19:11:59 +1100 From:matthew green Message-ID: <22915.1602144...@splode.eterna.com.au> | at least pacificnew is referenced by the build still: Yes, sorry, the way that tzdata updates get done makes it essentially impossible to test what is

re: CVS commit: src/external/public-domain/tz/dist

2020-10-08 Thread matthew green
"Robert Elz" writes: > Module Name: src > Committed By: kre > Date: Thu Oct 8 04:28:00 UTC 2020 > > Modified Files: > src/external/public-domain/tz/dist: TZDATA_VERSION > Removed Files: > src/external/public-domain/tz/dist: pacificnew systemv yearistype.sh at least

Re: CVS commit: src/external/mit/xorg/lib

2020-09-20 Thread maya
On Wed, Sep 16, 2020 at 06:26:45PM +, m...@netbsd.org wrote: > Since the background for this is an issue nobody else is experiencing, > can you at least report a bug for how to reach it? hello? in the original proposal joerg already said it has a chance of making opengl not reentrant. the

Re: CVS commit: src/external/mit/xorg/lib

2020-09-16 Thread maya
Since the background for this is an issue nobody else is experiencing, can you at least report a bug for how to reach it? On Wed, Sep 16, 2020 at 06:19:24PM +, Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Wed Sep 16 18:19:24 UTC 2020 > > Modified Files: >

Re: CVS commit: src/external/gpl3/gcc

2020-09-12 Thread Kamil Rytarowski
On 12.09.2020 23:36, Joerg Sonnenberger wrote: > On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote: >> On 12.09.2020 22:06, Joerg Sonnenberger wrote: >>> On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: On 11.09.2020 23:38, Joerg Sonnenberger wrote: > On

Re: CVS commit: src/external/gpl3/gcc

2020-09-12 Thread Joerg Sonnenberger
On Sat, Sep 12, 2020 at 10:24:16PM +0200, Kamil Rytarowski wrote: > On 12.09.2020 22:06, Joerg Sonnenberger wrote: > > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: > >> On 11.09.2020 23:38, Joerg Sonnenberger wrote: > >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil

Re: CVS commit: src/external/gpl3/gcc

2020-09-12 Thread Kamil Rytarowski
On 12.09.2020 22:06, Joerg Sonnenberger wrote: > On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: >> On 11.09.2020 23:38, Joerg Sonnenberger wrote: >>> On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: The current code is confusing, as it attempts to use

Re: CVS commit: src/external/gpl3/gcc

2020-09-12 Thread Joerg Sonnenberger
On Fri, Sep 11, 2020 at 11:45:42PM +0200, Kamil Rytarowski wrote: > On 11.09.2020 23:38, Joerg Sonnenberger wrote: > > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: > >> The current code is confusing, as it attempts to use unimplemented > >> _PTHREAD_GETTCB_EXT() and in one

Re: CVS commit: src/external/gpl3/gcc

2020-09-11 Thread Kamil Rytarowski
On 11.09.2020 23:38, Joerg Sonnenberger wrote: > On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: >> The current code is confusing, as it attempts to use unimplemented >> _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in >> other _lwp_getprivate(). This caused

Re: CVS commit: src/external/gpl3/gcc

2020-09-11 Thread Joerg Sonnenberger
On Fri, Sep 11, 2020 at 04:07:24PM +0200, Kamil Rytarowski wrote: > The current code is confusing, as it attempts to use unimplemented > _PTHREAD_GETTCB_EXT() and in one place uses _lwp_getprivate_fast() in > other _lwp_getprivate(). This caused my confusion... as I assumed that >

Re: CVS commit: src/external/gpl3/gcc

2020-09-11 Thread Kamil Rytarowski
On 11.09.2020 07:13, Rin Okuyama wrote: > Hi again, > > On 2020/09/10 21:53, Kamil Rytarowski wrote: >> Module Name:    src >> Committed By:    kamil >> Date:    Thu Sep 10 12:53:06 UTC 2020 >> >> Modified Files: >> src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common: >>    

Re: CVS commit: src/external/gpl3/gcc

2020-09-10 Thread Rin Okuyama
Hi again, On 2020/09/10 21:53, Kamil Rytarowski wrote: Module Name:src Committed By: kamil Date: Thu Sep 10 12:53:06 UTC 2020 Modified Files: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common: sanitizer_linux_libcdep.cc

re: CVS commit: src/external/gpl3/binutils/dist/bfd

2020-09-07 Thread matthew green
> Modified Files: > src/external/gpl3/binutils/dist/bfd: Makefile.am Makefile.in > > Log Message: > Fix `build.sh tools -j1` compilation, where bfd.h wasn't generated early > enough. FWIW, this looks right to me and not a hack. thanks. .mrg.

Re: CVS commit: src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common

2020-09-05 Thread Kamil Rytarowski
On 05.09.2020 15:35, matthew green wrote: > Module Name: src > Committed By: mrg > Date: Sat Sep 5 13:35:55 UTC 2020 > > Modified Files: > src/external/gpl3/gcc/dist/libsanitizer/sanitizer_common: > sanitizer_linux.cc sanitizer_linux.h sanitizer_linux_libcdep.cc >

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/m68k

2020-08-16 Thread Rin Okuyama
Sorry for the late reply. On 2020/08/11 1:16, Valery Ushakov wrote: This sounds eerily similar to port-macppc/54827 - there's quite a bit of confusion early on on my part there, but scroll to the last couple of mails. http://gnats.netbsd.org/54827 It looks like some logic changed in MI gcc8

re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/m68k

2020-08-10 Thread matthew green
> May be we should also check other ports for similar gotcha proactively? good idea. no other gcc/config/*/*netbsd* files define the nasty STACK_BOUNDARY macro so hopefully we're good now. thanks! .mrg.

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/m68k

2020-08-10 Thread Valery Ushakov
On Mon, Aug 10, 2020 at 06:24:39 +, Rin Okuyama wrote: > Modified Files: > src/external/gpl3/gcc/dist/gcc/config/m68k: netbsd-elf.h > > Log Message: > PR port-m68k/6 > > Reset STACK_BOUNDARY to default, 16, to fix strange freeze for amiga, > when kernel is compiled by GCC8. This

Re: CVS commit: src/external/mit/xorg/server/xorg-server/hw/sun

2020-07-23 Thread Izumi Tsutsui
> Module Name: src > Committed By: mrg > Date: Thu Jul 23 09:59:36 UTC 2020 > > Modified Files: > src/external/mit/xorg/server/xorg-server/hw/sun: Makefile.Xsun > > Log Message: > fix build: > - add .../xorg subdir to the path > - add dbe and present extensions, both wanted via

Re: CVS commit: src/external/bsd/kyua-cli

2020-07-02 Thread Christos Zoulas
In article <20200702140653.gf12...@mewburn.net>, Luke Mewburn wrote: >On 20-06-21 18:23, Christos Zoulas wrote: > | In article <20200621142616.60471f...@cvs.netbsd.org>, > | Luke Mewburn wrote: > | >-=-=-=-=-=- > | > > | >Module Name: src > | >Committed By: lukem > | >Date:

Re: CVS commit: src/external/bsd/kyua-cli

2020-07-02 Thread Luke Mewburn
On 20-06-21 18:23, Christos Zoulas wrote: | In article <20200621142616.60471f...@cvs.netbsd.org>, | Luke Mewburn wrote: | >-=-=-=-=-=- | > | >Module Name: src | >Committed By: lukem | >Date: Sun Jun 21 14:26:16 UTC 2020 | > | >Modified Files: | >

re: CVS commit: src/external/cddl/dtracetoolkit/dist/Man/man1m

2020-06-26 Thread matthew green
Sevan Janiyan writes: > On 25/06/2020 12:42, matthew green wrote: > > the manual in the tree might be called "foo.1m" by upstream, > > however, we should just install those into man8/foo.8. > > > > be nice to have a generic 1m -> 8 rule here, since i doubt > > that upstream will change from

Re: CVS commit: src/external/cddl/dtracetoolkit/dist/Man/man1m

2020-06-26 Thread Sevan Janiyan
On 25/06/2020 12:42, matthew green wrote: the manual in the tree might be called "foo.1m" by upstream, however, we should just install those into man8/foo.8. be nice to have a generic 1m -> 8 rule here, since i doubt that upstream will change from svr4/solaris naming. Ok, I'll take a look

re: CVS commit: src/external/cddl/dtracetoolkit/dist/Man/man1m

2020-06-25 Thread matthew green
> > The best way should be automatically converting them by some script > > when building. But if it is too difficult, we can install these files > > as is with minimum adjustments for our system; mandoc still works for > > them, although output is not very beautiful. > > I shouldn't have

Re: CVS commit: src/external/cddl/dtracetoolkit/dist/Man/man1m

2020-06-25 Thread Rin Okuyama
On 2020/06/25 17:39, Sevan Janiyan wrote: On 25/06/2020 08:48, Rin Okuyama wrote: > Thank you for working on this, but this makes sync with upstream > very difficult... I will be upstreaming these changes. upstream: github.com/opendtrace/toolkit Just need to find a better way for presenting

Re: CVS commit: src/external/cddl/dtracetoolkit/dist/Man/man1m

2020-06-25 Thread Sevan Janiyan
Hello, On 25/06/2020 08:48, Rin Okuyama wrote: > Thank you for working on this, but this makes sync with upstream > very difficult... I will be upstreaming these changes. upstream: github.com/opendtrace/toolkit Just need to find a better way for presenting the columns for field descriptions,

Re: CVS commit: src/external/cddl/dtracetoolkit/dist/Man/man1m

2020-06-25 Thread Rin Okuyama
Hi, On 2020/06/25 3:06, Sevan Janiyan wrote: Module Name:src Committed By: sevan Date: Wed Jun 24 18:06:01 UTC 2020 Modified Files: src/external/cddl/dtracetoolkit/dist/Man/man1m: opensnoop.1m Log Message: mdocify Thank you for working on this, but this makes sync

re: CVS commit: src/external/gpl3/gcc/usr.bin/host-libcpp

2020-06-24 Thread matthew green
> Modified Files: > src/external/gpl3/gcc/usr.bin/host-libcpp: Makefile > > Log Message: > PR bin/55411 (Akihiko HAYASHI) > > Remove stray ``&&'' introduced in the previous revision, so that > host tools are correctly passed to configure script. > > No similar problem for gcc.old. No

Re: CVS commit: src/external/bsd/kyua-cli

2020-06-21 Thread Christos Zoulas
In article <20200621142616.60471f...@cvs.netbsd.org>, Luke Mewburn wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: lukem >Date: Sun Jun 21 14:26:16 UTC 2020 > >Modified Files: > src/external/bsd/kyua-cli: Makefile.inc > >Log Message: >kyua-cli: avoid warning about

Re: CVS commit: src/external/gpl3/gcc

2020-06-02 Thread Rin Okuyama
On 2020/06/02 17:03, matthew green wrote: Module Name:src Committed By: mrg Date: Tue Jun 2 08:03:59 UTC 2020 Modified Files: src/external/gpl3/gcc: gcc2netbsd Log Message: don't elide fortran components. we'd like to revive g77-as-gfortran. To generate a diff of

Re: CVS commit: src/external/bsd/ntp/bin/ntpd

2020-05-29 Thread Kamil Rytarowski
On 29.05.2020 16:15, Tobias Nygren wrote: > On Fri, 29 May 2020 16:08:30 +0200 > Joerg Sonnenberger wrote: > >> On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote: >>> Module Name:src >>> Committed By: kamil >>> Date: Fri May 29 10:53:02 UTC 2020 >>> >>>

Re: CVS commit: src/external/bsd/ntp/bin/ntpd

2020-05-29 Thread Tobias Nygren
On Fri, 29 May 2020 16:08:30 +0200 Joerg Sonnenberger wrote: > On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote: > > Module Name:src > > Committed By: kamil > > Date: Fri May 29 10:53:02 UTC 2020 > > > > Modified Files: > >

Re: CVS commit: src/external/bsd/ntp/bin/ntpd

2020-05-29 Thread Joerg Sonnenberger
On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Fri May 29 10:53:02 UTC 2020 > > Modified Files: > src/external/bsd/ntp/bin/ntpd: Makefile > > Log Message: > Fix the ntpd build with Clang/LLVM > > Set

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

2020-05-18 Thread Jared McNeill
Unfortunately this breaks building on a 9.0 arm64 host because it is picking up /usr/include/aarch64/armreg.h and the one in 9.0 is missing a bunch of stuff. It works when using armreg.h from the source tree instead, eg: -#include +#include "/path/to/src/sys/arch/aarch64/include/armreg.h"

Re: CVS commit: src/external/mpl/dhcp/dist/common

2020-05-15 Thread Christos Zoulas
In article <20200515123104.297c5f...@cvs.netbsd.org>, Emmanuel Dreyfus wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: manu >Date: Fri May 15 12:31:04 UTC 2020 > >Modified Files: > src/external/mpl/dhcp/dist/common: bpf.c discover.c lpf.c packet.c > raw.c

Re: CVS commit: src/external/bsd/dhcpcd/dist/src

2020-05-14 Thread Christos Zoulas
In article <95034282-ebf6-c1d5-8bb1-9258ee825...@marples.name>, Roy Marples wrote: >On 10/05/2020 18:58, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sun May 10 17:58:16 UTC 2020 >> >> Modified Files: >>

Re: CVS commit: src/external/bsd/dhcpcd/dist/src

2020-05-14 Thread Roy Marples
On 10/05/2020 18:58, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Sun May 10 17:58:16 UTC 2020 Modified Files: src/external/bsd/dhcpcd/dist/src: dhcpcd.c Log Message: Add SIGPIPE to the list of dhcpcd affected signals since we sigignore it. Why?

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

2020-05-07 Thread J. Hannken-Illjes
> On May 7, 2020, at 5:47 PM, Taylor R Campbell > wrote: > >> Module Name:src >> Committed By: hannken >> Date: Thu May 7 09:12:03 UTC 2020 >> >> Modified Files: >>src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c >> >> Log Message: >> Revert Rev. 1.63 and

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

2020-05-07 Thread Taylor R Campbell
> Module Name:src > Committed By: hannken > Date: Thu May 7 09:12:03 UTC 2020 > > Modified Files: > src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c > > Log Message: > Revert Rev. 1.63 and add a comment why we have to zil_commit() here: > > Operation

Re: CVS commit: src/external/gpl3/gdb/lib/libgdb

2020-04-29 Thread Christos Zoulas
In article <20200429110459.0d9bcf...@cvs.netbsd.org>, Rin Okuyama wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: rin >Date: Wed Apr 29 11:04:58 UTC 2020 > >Modified Files: > src/external/gpl3/gdb/lib/libgdb: Makefile > >Log Message: >PR toolchain/54820 >PR

Re: CVS commit: src/external/gpl3

2020-03-28 Thread Kamil Rytarowski
On 28.03.2020 05:39, matthew green wrote: >> Date:Sat, 28 Mar 2020 11:46:29 +1100 >> From:matthew green >> Message-ID: <15233.1585356...@splode.eterna.com.au> >> >> | can we just leave this as-is and let netbsd GCC people care? >> >> Only if the GCC people do care,

Re: CVS commit: src/external/gpl3

2020-03-28 Thread Martin Husemann
On Sat, Mar 28, 2020 at 03:39:34PM +1100, matthew green wrote: > we want both changes (libiberty, and my stdio.h/P_tmpdir > change.) we want to support old netbsd, non-netbsd, .. > whatever build hosts. Can we have them in 8.2 please? Martin

re: CVS commit: src/external/gpl3

2020-03-27 Thread matthew green
> Date:Sat, 28 Mar 2020 11:46:29 +1100 > From:matthew green > Message-ID: <15233.1585356...@splode.eterna.com.au> > > | can we just leave this as-is and let netbsd GCC people care? > > Only if the GCC people do care, and understand the issue, and > implement what

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Robert Elz
Date:Sat, 28 Mar 2020 11:46:29 +1100 From:matthew green Message-ID: <15233.1585356...@splode.eterna.com.au> | can we just leave this as-is and let netbsd GCC people care? Only if the GCC people do care, and understand the issue, and implement what we want

re: CVS commit: src/external/gpl3

2020-03-27 Thread matthew green
i don't like this "don't care about netbsd-8" feeling i'm hearing when netbsd-9 is so freshly released. we only *just* dropped caring about netbsd-7. please care about netbsd-8 for now. .mrg.

re: CVS commit: src/external/gpl3

2020-03-27 Thread matthew green
can we just leave this as-is and let netbsd GCC people care?

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Martin Husemann
On Fri, Mar 27, 2020 at 02:11:36PM -0400, Greg Troxel wrote: > I don't see why we don't care about 8. Given our release policy, that > is supported until 10 is released. It didn't have the local patch that Kamil wants to remove, so no change there - but if we can fix it there too that would be a

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Greg Troxel
Great to hear of progress. I don't see why we don't care about 8. Given our release policy, that is supported until 10 is released.

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Kamil Rytarowski
On 27.03.2020 18:42, Martin Husemann wrote: > On Fri, Mar 27, 2020 at 06:36:29PM +0100, Kamil Rytarowski wrote: >> I tested the code without our local patch as mentioned in my commit, >> even in the snapshot 1 commit before jak@'s change. >> >> In all the cases I get P_tmpdir defined and pointing

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Martin Husemann
On Fri, Mar 27, 2020 at 06:36:29PM +0100, Kamil Rytarowski wrote: > I tested the code without our local patch as mentioned in my commit, > even in the snapshot 1 commit before jak@'s change. > > In all the cases I get P_tmpdir defined and pointing to "/tmp/". > > I have not tested it on NetBSD-8

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Kamil Rytarowski
On 27.03.2020 18:24, Martin Husemann wrote: > On Fri, Mar 27, 2020 at 06:14:24PM +0100, Kamil Rytarowski wrote: >> On 27.03.2020 16:01, Martin Husemann wrote: >>> Which compiler version did you test? >>> >> >> I tested on NetBSD HEAD GCC style distribution as host. > > Not sure I understand. You

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Martin Husemann
On Fri, Mar 27, 2020 at 06:14:24PM +0100, Kamil Rytarowski wrote: > On 27.03.2020 16:01, Martin Husemann wrote: > > Which compiler version did you test? > > > > I tested on NetBSD HEAD GCC style distribution as host. Not sure I understand. You need to test the in-tree build with the change

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Kamil Rytarowski
On 27.03.2020 16:01, Martin Husemann wrote: > Which compiler version did you test? > I tested on NetBSD HEAD GCC style distribution as host. $ uname -rms NetBSD 9.99.51 amd64 > I see this on netbsd-8: > >> echo $TMPDIR > TMPDIR: Undefined variable. >> ktrace -i $TOOLDIR/bin/x86_64--netbsd-gcc

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Martin Husemann
Which compiler version did you test? I see this on netbsd-8: > echo $TMPDIR TMPDIR: Undefined variable. > ktrace -i $TOOLDIR/bin/x86_64--netbsd-gcc base64.c [..] > kdump | fgrep tmp [..] 19418 1 collect2 NAMI "/var/tmp//ccs9D5nv.le" 19418 1 collect2 NAMI "/var/tmp//ccs9D5nv.le"

Re: CVS commit: src/external/gpl3

2020-03-27 Thread Kamil Rytarowski
I've found out that this patch in not needed, at least on NetBSD and likely Linux. The algorithm to pick tmpdir is as follows: - check for memoized tmpdir - try env variables - try P_tmpdir - try /var/tmp, then /usr/tmp, then /tmp - fallback to current dir ('.') - save memoized tmpdir

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Robert Elz
Date:Thu, 26 Mar 2020 23:22:57 + From:Andrew Doran Message-ID: <20200326232257.gf27...@homeworld.netbsd.org> | > Modern CPUs like Ryzen Threadripper 3990X can execute that extra amount | > of instructions (around 600) in a single clock cycle. | |

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Andrew Doran
On Thu, Mar 26, 2020 at 06:07:54PM +0100, Kamil Rytarowski wrote: > On 26.03.2020 17:49, Robert Elz wrote: > > Date:Thu, 26 Mar 2020 16:28:18 +0100 > > From:Kamil Rytarowski > > Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com> > > > > > > | That is

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Robert Elz
Date:Thu, 26 Mar 2020 18:07:54 +0100 From:Kamil Rytarowski Message-ID: <723e979c-cb16-1a39-a51e-9d756f372...@gmx.com> | But nonetheless, I'm trying to fix it un GCC without TMPDIR. Not without, just without requiring. Something like tempnam(3) works - if TMPDIR

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Kamil Rytarowski
On 26.03.2020 17:49, Robert Elz wrote: > Date:Thu, 26 Mar 2020 16:28:18 +0100 > From:Kamil Rytarowski > Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com> > > > | That is negligible cost of getting TMPDIR propagated to most programs. > > Sure, it isn't much,

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Robert Elz
Date:Thu, 26 Mar 2020 16:28:18 +0100 From:Kamil Rytarowski Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com> | That is negligible cost of getting TMPDIR propagated to most programs. Sure, it isn't much, for one program, but when you're running tens of

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Kamil Rytarowski
On 26.03.2020 17:03, Kamil Rytarowski wrote: > On 26.03.2020 16:17, Greg Troxel wrote: >> I don't think we can go from "upstream is unwilling to do X" >> to "impose pain on NetBSD" by making "divergence bad" be the >> highest-weighted concern.   We have to say "what is the minimally >> painful way

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Kamil Rytarowski
On 26.03.2020 16:17, Greg Troxel wrote: > I don't think we can go from "upstream is unwilling to do X" > to "impose pain on NetBSD" by making "divergence bad" be the > highest-weighted concern.   We have to say "what is the minimally > painful way to cope". I agree here that we want to get /tmp

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Taylor R Campbell
> Date: Thu, 26 Mar 2020 14:57:40 +0100 > From: Kamil Rytarowski > > Maybe we could specify TMPDIR somewhere in /etc and point to /tmp? > > The build of tools could be fixed independently. It is wrong for gcc to abuse /var/tmp for files that aren't meaningfully persistent, just like it would

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Kamil Rytarowski
On 26.03.2020 16:02, Robert Elz wrote: > EVery extra env var has a cost in every exec of absolutely everything. As this is true.. but as I have benchmarked it. For true(1) on amd64, we execute 0.05% more instructions for extra TMPDIR environment variable. $ ./singlestepper true Total count:

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Greg Troxel
Generally speaking divergence with upstream is a problem and we lost these changes anyway in pkgsrc and every standalone GNU toolchain copy. Agreed that divergence is a problem, but so is having bugs. It's a question of the right balance in each case. Finding a creative way to make this at

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Kamil Rytarowski
On 26.03.2020 15:52, Greg Troxel wrote: > What is the real problem here? I think it's great that NetBSD-specific > fixes are being upstreamed, and that we are reducing gratuitous changes > from upstream. But upstream's position that the default tmp should be > /var/tmp is at odds with our and

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Greg Troxel
Greg Troxel writes: > It seem really obvious to me, and obvious that it is netbsd consensus, > that a tool that needs tmp (without needing persistence) should default > to /tmp. So I think it's unreasonable to follow upstream here, and > unreasonable to ask everybody to either inherit some

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Robert Elz
Date:Thu, 26 Mar 2020 15:11:46 +0100 From:Kamil Rytarowski Message-ID: <26eaf84f-616a-d48b-9a2f-7dd74cd69...@gmx.com> | Right. Addressing tools build independently (honoring TMPDIR?) This we should do. | defining TMPDIR in /etc shell profile for common use

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Greg Troxel
Kamil Rytarowski writes: > On 26.03.2020 15:01, Martin Husemann wrote: >> On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote: >>> The build of tools could be fixed independently. >> The problem is that we build the whole system with the tools gcc, and that >> gcc misbehaves (or so

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Kamil Rytarowski
On 26.03.2020 15:01, Martin Husemann wrote: > On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote: >> The build of tools could be fixed independently. > The problem is that we build the whole system with the tools gcc, and that > gcc misbehaves (or so I understood). > > So pointing

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Martin Husemann
On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote: > The build of tools could be fixed independently. The problem is that we build the whole system with the tools gcc, and that gcc misbehaves (or so I understood). So pointing TMPDIR anywhere does not help. Martin

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Kamil Rytarowski
On 26.03.2020 09:48, Martin Husemann wrote: > On Thu, Mar 26, 2020 at 12:51:24AM +, Taylor R Campbell wrote: >> We should keep the change. There is no semantic justification for >> putting build-time temporary files in the directory for temporary >> files that are meant to persist across

Re: CVS commit: src/external/gpl3

2020-03-26 Thread Martin Husemann
On Thu, Mar 26, 2020 at 12:51:24AM +, Taylor R Campbell wrote: > We should keep the change. There is no semantic justification for > putting build-time temporary files in the directory for temporary > files that are meant to persist across reboot. These temporary files > _cannot_ be used if

Re: CVS commit: src/external/gpl3

2020-03-25 Thread Robert Elz
Date:Wed, 25 Mar 2020 20:59:59 -0400 From:Greg Troxel Message-ID: | I'll fourth this sentiment. Me too (5th...) The idea that /tmp is smaller than /var/tmp (or has less available space) is based upon historic RAM sizes, my /tmp currently has about 10 times as

Re: CVS commit: src/external/gpl3

2020-03-25 Thread Greg Troxel
Taylor R Campbell writes: >> Do we insist on this patch? Can we remove it from local sources? > > We should keep the change. There is no semantic justification for > putting build-time temporary files in the directory for temporary > files that are meant to persist across reboot. These

Re: CVS commit: src/external/gpl3

2020-03-25 Thread Taylor R Campbell
> Date: Thu, 26 Mar 2020 01:26:05 +0100 > From: Kamil Rytarowski > > Upstream (GCC) is strongly against this change (even under __NetBSD__ > ifdef) as /var/tmp is typically larger than /tmp: > > > I'd strongly recommend against this as-is. > > > > The whole reason we prefer /var/tmp is because

  1   2   3   4   5   6   7   8   9   10   >