re: current USE_SSP=yes build failure

rudolf writes: > Hi, > > I have "USE_SSP=yes" in mk.conf and the build is failing with: > > --- dependall-drivers --- > /usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting/drmmode_display.c: > > In function 'drmmode_crtc_gamma_set': >

daily CVS update output

Updating src tree: P src/include/sched.h P src/lib/libc/sys/clone.2 P src/sys/dev/ic/ahcisata_core.c P src/sys/dev/ic/bcmgenet.c P src/sys/dev/ic/nslm7x.c P src/sys/dev/ic/nvmereg.h P src/sys/dev/ic/nvmevar.h P src/sys/dev/ic/rtl8169.c P src/sys/dev/ic/tulip.c P src/sys/dev/ic/tulipreg.h P

current USE_SSP=yes build failure

Hi, I have "USE_SSP=yes" in mk.conf and the build is failing with: --- dependall-drivers --- /usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting/drmmode_display.c: In function 'drmmode_crtc_gamma_set':

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: 2022.08.01.15.16.05 wiz src/include/sched.h,v 1.15 Logs can be found at:

Re: namespace pollution? clone()

The test is fixed now. kre

Re: namespace pollution? clone()

On Mon, Aug 01, 2022 at 05:11:53PM +0200, Thomas Klausner wrote: > I don't understand why we expose __clone() in a public header at all, > but I understand your comments to result in the attached patch. It is used in tests:

Automated report: NetBSD-current/i386 build failure

This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2022.08.01.14.34.01. An extract from the build.sh output follows: --- .gdbinit --- --- dependall-usr.bin ---

Re: namespace pollution? clone()

On Mon, Aug 01, 2022 at 06:06:19PM +0300, Valeriy E. Ushakov wrote: > On Mon, Aug 01, 2022 at 16:50:14 +0200, Thomas Klausner wrote: > > > On Mon, Aug 01, 2022 at 05:45:23PM +0300, Valeriy E. Ushakov wrote: > > > Shouldn't we expose __clone(2) (the real symbol in the reserved > > > namespace)

Re: namespace pollution? clone()

On Mon, Aug 01, 2022 at 16:50:14 +0200, Thomas Klausner wrote: > On Mon, Aug 01, 2022 at 05:45:23PM +0300, Valeriy E. Ushakov wrote: > > Shouldn't we expose __clone(2) (the real symbol in the reserved > > namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias > > under _GNU_SOURCE?

Re: namespace pollution? clone()

On Mon, Aug 01, 2022 at 05:45:23PM +0300, Valeriy E. Ushakov wrote: > Shouldn't we expose __clone(2) (the real symbol in the reserved > namespace) under _NETBSD_SOURCE and only hide clone(2) weak alias > under _GNU_SOURCE? You kinda sidestep some potential issues here in > this case b/c __clone

Re: namespace pollution? clone()

On Mon, Aug 01, 2022 at 15:57:19 +0200, Thomas Klausner wrote: > On Tue, Jul 26, 2022 at 03:03:54PM +0200, Martin Husemann wrote: > > On Tue, Jul 26, 2022 at 03:46:14PM +0300, Valery Ushakov wrote: > > > On Linux clone(2) is declared only for _GNU_SOURCE, which explains why > > > linux doesn't

Re: namespace pollution? clone()

On 2022/08/01 23:22, Thomas Klausner wrote: On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote: On 2022/08/01 23:13, Martin Husemann wrote: On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: The attached diff survived a complete amd64-current build. Ok to commit?

Re: namespace pollution? clone()

On Mon, Aug 01, 2022 at 07:32:26AM -0700, Jason Thorpe wrote: > > > On Aug 1, 2022, at 7:22 AM, Thomas Klausner wrote: > > > > On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote: > >> On 2022/08/01 23:13, Martin Husemann wrote: > >>> On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas

Re: namespace pollution? clone()

> On Aug 1, 2022, at 7:22 AM, Thomas Klausner wrote: > > On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote: >> On 2022/08/01 23:13, Martin Husemann wrote: >>> On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: The attached diff survived a complete amd64-current

Re: namespace pollution? clone()

On Mon, Aug 01, 2022 at 11:20:11PM +0900, Rin Okuyama wrote: > On 2022/08/01 23:13, Martin Husemann wrote: > > On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: > > > The attached diff survived a complete amd64-current build. Ok to commit? > > > > Looks good to me. > > Can you

Re: namespace pollution? clone()

On 2022/08/01 23:13, Martin Husemann wrote: On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: The attached diff survived a complete amd64-current build. Ok to commit? Looks good to me. Can you please mention _GNU_SOURCE in clone(2)? Thanks, rin

Re: namespace pollution? clone()

On Mon, Aug 01, 2022 at 03:57:19PM +0200, Thomas Klausner wrote: > The attached diff survived a complete amd64-current build. Ok to commit? Looks good to me. Martin

Re: namespace pollution? clone()

On Tue, Jul 26, 2022 at 03:03:54PM +0200, Martin Husemann wrote: > On Tue, Jul 26, 2022 at 03:46:14PM +0300, Valery Ushakov wrote: > > On Linux clone(2) is declared only for _GNU_SOURCE, which explains why > > linux doesn't run into the name clash. I gather we should follow > > suit, as that's

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: 2022.08.01.10.30.28 kre src/sys/dev/ic/tulip.c,v 1.208 Logs can be found at:

Automated report: NetBSD-current/i386 build failure

This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, using sources from CVS date 2022.08.01.08.09.30. An extract from the build.sh output follows: mv -f kern_uipc_socket_50.d.tmp