Re: Can't build evbarm

2024-01-27 Thread Adam
> Now that Christos moved the function around, that declaration in the
> header is just noise, and could be removed.

Thank you for fixing this.

Adam


daily CVS update output

2024-01-27 Thread NetBSD source update


Updating src tree:
P src/distrib/sets/lists/base/mi
P src/distrib/sets/lists/tests/mi
P src/doc/3RDPARTY
P src/doc/CHANGES
P src/etc/mtree/NetBSD.dist.base
P src/external/mit/xorg/server/xorg-server.old/Makefile.servermod
P src/external/mit/xorg/server/xorg-server.old/hw/xfree86/dixmods/fb/Makefile
P src/lib/libc/stdlib/Makefile.inc
P src/lib/libm/src/e_acoshl.c
P src/lib/libm/src/e_acosl.c
P src/lib/libm/src/e_asinl.c
P src/lib/libm/src/e_atanhl.c
P src/lib/libm/src/e_coshl.c
P src/lib/libm/src/s_asinhl.c
P src/lib/libm/src/s_logl.c
P src/lib/libm/src/s_tanhl.c
P src/share/terminfo/import
P src/share/terminfo/terminfo
P src/sys/arch/evbppc/wii/dev/wiifb.c
P src/tests/lib/libutil/t_snprintb.c
P src/tests/usr.bin/xlint/lint1/check-expect.lua
P src/tests/usr.bin/xlint/lint1/msg_252.c
U src/tests/usr.bin/xlint/lint1/platform_ilp32_c90.c
U src/tests/usr.bin/xlint/lint1/platform_ilp32_c99.c
U src/tests/usr.bin/xlint/lint1/platform_ilp32_trad.c
U src/tests/usr.bin/xlint/lint1/platform_lp64_c90.c
U src/tests/usr.bin/xlint/lint1/platform_lp64_c99.c
U src/tests/usr.bin/xlint/lint1/platform_lp64_trad.c
P src/usr.bin/getconf/getconf.c
P src/usr.bin/xlint/lint1/lex.c

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  44337636 Jan 28 03:03 ls-lRA.gz


Automated report: NetBSD-current/i386 test failure

2024-01-27 Thread NetBSD Test Fixture
This is an automatically generated notice of new failures of the
NetBSD test suite.

The newly failing test cases are:

usr.bin/xlint/lint1/t_integration:lex_integer_ilp32
usr.bin/xlint/lint1/t_integration:msg_218

The above tests failed in each of the last 4 test runs, and passed in
at least 26 consecutive runs before that.

The following commits were made between the last successful test and
the first failed test:

2024.01.27.20.03.14 rillig 
src/tests/usr.bin/xlint/lint1/platform_ilp32_c90.c 1.2
2024.01.27.20.03.14 rillig 
src/tests/usr.bin/xlint/lint1/platform_ilp32_c99.c 1.2
2024.01.27.20.03.14 rillig 
src/tests/usr.bin/xlint/lint1/platform_ilp32_trad.c 1.2
2024.01.27.20.03.14 rillig 
src/tests/usr.bin/xlint/lint1/platform_lp64_c90.c 1.2
2024.01.27.20.03.14 rillig 
src/tests/usr.bin/xlint/lint1/platform_lp64_c99.c 1.2
2024.01.27.20.03.14 rillig 
src/tests/usr.bin/xlint/lint1/platform_lp64_trad.c 1.2
2024.01.27.20.03.14 rillig src/usr.bin/xlint/lint1/lex.c 1.203

Logs can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2024.01.html#2024.01.27.20.03.14


Re: GitHub mirror stopped mirroring

2024-01-27 Thread Lloyd Parkes
On Sat, 2024-01-27 at 16:17 -0800, Chris Hanson wrote:
> It looks like there are CVS commits that haven’t made it to the
> GitHub mirror yet.
> 
> Anyone know what’s up with that?
> 
>   -- Chris
> 

The Mercurial mirror also hasn't been updated for a week.

Ngā mihi,
Lloyd



GitHub mirror stopped mirroring

2024-01-27 Thread Chris Hanson
It looks like there are CVS commits that haven’t made it to the GitHub mirror 
yet.

Anyone know what’s up with that?

  -- Chris



Re: Can't build evbarm

2024-01-27 Thread Martin Husemann
On Sat, Jan 27, 2024 at 03:33:06PM +0700, Robert Elz wrote:
> Now that Christos moved the function around, that declaration in the
> header is just noise, and could be removed.

Yes, that would be consistent then (but isn't it against the new style
rules?)

Martin


Re: Can't build evbarm

2024-01-27 Thread Robert Elz
Date:Sat, 27 Jan 2024 09:11:58 +0100
From:Martin Husemann 
Message-ID:  <20240127081158.gb16...@mail.duskware.de>

  | Because the declaration in the relevant header is already there,

Now that Christos moved the function around, that declaration in the
header is just noise, and could be removed.

kre




Re: Can't build evbarm

2024-01-27 Thread Robert Elz
Date:Fri, 26 Jan 2024 21:09:30 +0100
From:Adam 
Message-ID:  <7be03ef0-a516-4102-951a-be8a0d468...@netbsd.org>

  | Why not just change the order?

Christos has done that now, so I guess that more or less "fixes" the
issue.

I didn't want to do it that way, as it still leaves _LIBC_INTERNAL
unset when building the parts of libc which go in the tools libcompat
and one day, we're likely to have the same problem again, for the same
reason, and I would have preferred to have the Makefile(s) for the
tools libcompat build fixed instead, which would have also solved it.

If the "static" hadn't been commented out for MD2Transform() this would
certainly have been the right way (then there would have not been any
prototype in any md2.h, _LIBC_INTERNAL or not) - either that or just
adding a prototype to the .c file (sometimes that is necessary, as there
can be 2 such functions which refer to each other, they both can't come
first).

In this case moving it, rather than adding a prototype is better, as
the prototype would have needed another commented out "static" in it,
to match the actual function, and that would have been overboard.

In any case, my strategy had been to leave md2.c as it was, and attempt to
get someone who knew how, to fix the Makefile so that _LIBC_TNTERNAL
was defined (those functions are still part of a libc lookalike,
even when in libcompat so deserve to be compiled the same way as in
libc).   I guess we just wait for the next time.

kre



Re: Can't build evbarm

2024-01-27 Thread Martin Husemann
On Fri, Jan 26, 2024 at 09:09:30PM +0100, Adam wrote:
> Simple and elegant. No hacks involved.

Because the declaration in the relevant header is already there, and
the order does not matter. But the #ifdef around the declaration needs
to do the right thing. No need to move things around and its like this code
is compiled everwhere else where it is used.

Martin