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':
> /usr/xsrc/external/mit/xorg-server/dist/hw/
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 src/sy
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':
/usr/xsrc/external/mit/xorg-server/dist/hw/xfree86/drivers/modesetting/drm
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:
http://releng.NetBSD.org/b5reports/i386/commits-2022.08.html#2022.08.01.15.16
The test is fixed now.
kre
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:
/tmp/build/2022.08.01.14.34.01-i386/src/tests/lib/libc/sys/t_clone.c:
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 ---
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) unde
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? You
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 is
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 run
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?
Looks
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 Klau
> 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 buil
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 plea
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
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
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 wha
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:
http://releng.NetBSD.org/b5reports/i386/commits-2022.08.html#2022.08.01.1
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 kern_uipc_socket_5
20 matches
Mail list logo