Date:Sat, 21 Sep 2024 20:48:51 +
From:"Robert Elz"
Message-ID: <20240921204851.18e75f...@cvs.netbsd.org>
| In !TINYPROG versions of sh, make the builtin "shift" builtin command
| perform a rotate instead or shift if given a numeric arg (which is
| otherwise
Hi,
On 2024/09/19 3:33, Andrius V wrote:
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Sep 18 00:44:03 UTC 2024
Modified Files:
src/sys/arch/i386/stand/lib: libi386.h
Log Message:
i386/stand: Remove XMS leftover from
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote:
>
> Module Name:src
> Committed By: rin
> Date: Wed Sep 18 00:44:03 UTC 2024
>
> Modified Files:
> src/sys/arch/i386/stand/lib: libi386.h
>
> Log Message:
> i386/stand: Remove XMS leftover from libi386.h, NFC
>
> PR port-i3
Thank you very much for kind & rapid response!!
rin
On 2024/09/18 10:34, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Wed Sep 18 01:34:08 UTC 2024
Modified Files:
src/sys/arch/mac68k/dev: adb.c
Log Message:
The delay is only required for machines with
Hi,
Can you please localize this quirk only for the affected machines?
It seems too much to me, to have 5 sec delay for irrelevant machines.
Thanks,
rin
On 2024/09/15 5:56, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Sat Sep 14 20:56:51 UTC 2024
Modified Fil
On Wed, Sep 11, 2024 at 05:17:45 +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Wed Sep 11 05:17:45 UTC 2024
>
> Modified Files:
> src/sys/arch/x86/x86: intr.c
>
> Log Message:
> apply some more diagnostic checks for x86 interrupts
How does this mix wi
> Date: Sat, 14 Sep 2024 22:26:37 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article ,
> Thomas Klausner wrote:
> >On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote:
> >> POSIX.1-2024 removes asctime_r and ctime_r and does not let
> >> libraries define
chris...@astron.com (Christos Zoulas) writes:
>>> POSIX.1-2024 removes asctime_r and ctime_r and does not let
>>> libraries define them, so remove them except when needed to
>>> conform to earlier POSIX. These functions are dangerous as they
>>> can overrun user buffers. If you s
In article ,
Thomas Klausner wrote:
>On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Sep 11 13:50:35 UTC 2024
>>
>> Modified Files:
>> src/lib/libc/compat/time: compat_localtime.c
>> src/l
This was also supposed to include in the log message:
Include mqueue-based entries only if built with MQUEUE option.
On Sat, 14 Sep 2024, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sat Sep 14 01:37:42 UTC 2024
Modified Files:
src/sys/miscfs/procf
Hi,
Christos Zoulas writes:
> And committed.
Thank you very much for your quick fix.
It works fine for me now.
> christos
>
>
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Sep 11 13:50:35 UTC 2024
>
> Modified Files:
> src/lib/libc/compat/time: compat_localtime.c
> src/lib/libc/time: CONTRIBUTING Makefile Makefile.inc NEWS asc
And committed.
christos
On 2024-09-11 11:18 am, Taylor R Campbell wrote:
Date: Thu, 12 Sep 2024 00:05:24 +0900
From: Ryo ONODERA
"Taylor R Campbell" writes:
> sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
>
> These are non-standard extensions, so they should not be exposed by,
> e.g., _XOPEN_SOURCE=70
> Date: Thu, 12 Sep 2024 00:05:24 +0900
> From: Ryo ONODERA
>
> "Taylor R Campbell" writes:
>
> > sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
> >
> > These are non-standard extensions, so they should not be exposed by,
> > e.g., _XOPEN_SOURCE=700.
> >
> > PR standards/57807: #i
Hi,
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Mon Sep 9 18:17:14 UTC 2024
>
> Modified Files:
> src/sys/sys: endian.h
>
> Log Message:
> sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
>
> These are non-standard extensions, so t
Date:Sun, 8 Sep 2024 22:35:02 +
From:"Robert Elz"
Message-ID: <20240908223502.927a4f...@cvs.netbsd.org>
| Modified Files:
| src/distrib/sets/lists/base: mi
|
| Log Message:
| One more mozilla-rootcerts file that is now obsolete.
| This fixes one cu
On Wed, Aug 21, 2024 at 01:42:28AM -0700, John Nemeth wrote:
> } Log Message:
> } Add Areca ARC-1224
>
> I noticed that you mentioned newer Areca devices on icb. Is
> there a particular device that you're interested in. I have an
> updated version of arcmsr(4) that I've been meaning to clea
On Aug 20, 22:44, "Tom Spindler" wrote:
}
} Module Name: src
} Committed By: dogcow
} Date: Tue Aug 20 22:44:04 UTC 2024
}
} Modified Files:
} src/sys/dev/pci: pcidevs
}
} Log Message:
} Add Areca ARC-1224
Hi Tom,
I noticed that you mentioned newer Areca devices on icb. Is
> Date: Sun, 18 Aug 2024 19:55:10 +0200
> From: Roland Illig
>
> Am 18.08.2024 um 15:39 schrieb Taylor R Campbell:
> > Please revert the casts and use `LINTFLAGS.mbrtoc8.c+= -X 132' instead
> > until it is fixed.
>
> It is fixed.
Awesome, thanks!
Am 18.08.2024 um 15:39 schrieb Taylor R Campbell:
>> Date: Sat, 17 Aug 2024 17:55:28 -0400
>> From: Christos Zoulas
>>
>> There is only one bug. I have sent mail to Roland about it and will revert
>> once it is fixed.
>>
>> The rest are:
>> - cast through (void *)
>> - add casts because __BITS re
> Date: Sat, 17 Aug 2024 17:55:28 -0400
> From: Christos Zoulas
>
> There is only one bug. I have sent mail to Roland about it and will revert
> once it is fixed.
>
> The rest are:
> - cast through (void *)
> - add casts because __BITS returns uintmax_t which is wider than the
> destination t
Hi,
For __CTASSERT v.s. case label:
https://nxr.netbsd.org/xref/src/lib/libc/locale/c8rtomb.c#225
not only lint(1), but also GCC 10.5 does not accept this, which
results in build failures for platforms still using gcc.old:
https://releng.netbsd.org/builds/HEAD/202408171750Z/
Can we just drop
Done :) Thanks for your kind words!
rin
On 2024/08/17 3:41, Christos Zoulas wrote:
Rin, thank you so much for working on this. LG[reat]TM. Please commit.
christos
On Aug 16, 2024, at 6:06 AM, Rin Okuyama wrote:
Hi,
I've changed mknative-gdb to generate *.info by using makeinfo(1)
provided
> Date: Sat, 17 Aug 2024 17:55:28 -0400
> From: Christos Zoulas
>
> There is only one bug. I have sent mail to Roland about it and will revert
> once it is fixed.
>
> The rest are:
> - cast through (void *)
There is no need to cast through (void *) -- not in C, not in KNF, and
not for any oth
There is only one bug. I have sent mail to Roland about it and will revert once
it is fixed.
The rest are:
- cast through (void *)
- add casts because __BITS returns uintmax_t which is wider than the
destination types.
christos
> On Aug 17, 2024, at 5:29 PM, Taylor R Campbell wrote:
>
>> Mo
> Module Name:src
> Committed By: christos
> Date: Sat Aug 17 20:08:13 UTC 2024
>
> Modified Files:
> src/lib/libc/locale: c16rtomb.c c8rtomb.c mbrtoc16.c mbrtoc32.c
> mbrtoc8.c
>
> Log Message:
> pass lint, XXX see lint bug.
Can you please arrange to fix the
Greg Troxel wrote in
:
|Valery Ushakov writes:
|
|> On Fri, Aug 16, 2024 at 19:06:15 +0900, Rin Okuyama wrote:
|>
|>> I've changed mknative-gdb to generate *.info by using makeinfo(1)
|>> provided by pkgsrc-2024Q2:
|>>
|>> https://github.com/IIJ-NetBSD/netbsd-src/compare/master...rokuyam
Rin, thank you so much for working on this. LG[reat]TM. Please commit.
christos
> On Aug 16, 2024, at 6:06 AM, Rin Okuyama wrote:
>
> Hi,
>
> I've changed mknative-gdb to generate *.info by using makeinfo(1)
> provided by pkgsrc-2024Q2:
>
> https://github.com/IIJ-NetBSD/netbsd-src/compare/mas
Valery Ushakov writes:
> On Fri, Aug 16, 2024 at 19:06:15 +0900, Rin Okuyama wrote:
>
>> I've changed mknative-gdb to generate *.info by using makeinfo(1)
>> provided by pkgsrc-2024Q2:
>>
>> https://github.com/IIJ-NetBSD/netbsd-src/compare/master...rokuyama:netbsd-src:exp/mknative-gdb-makeinfo
>
On Fri, Aug 16, 2024 at 19:06:15 +0900, Rin Okuyama wrote:
> I've changed mknative-gdb to generate *.info by using makeinfo(1)
> provided by pkgsrc-2024Q2:
>
> https://github.com/IIJ-NetBSD/netbsd-src/compare/master...rokuyama:netbsd-src:exp/mknative-gdb-makeinfo
>
> Then, pre-generated infos ar
Hi,
I've changed mknative-gdb to generate *.info by using makeinfo(1)
provided by pkgsrc-2024Q2:
https://github.com/IIJ-NetBSD/netbsd-src/compare/master...rokuyama:netbsd-src:exp/mknative-gdb-makeinfo
Then, pre-generated infos are installed for normal builds. Also,
in this branch:
- Add some m
On Thu, 15 Aug 2024, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Thu Aug 15 21:51:35 UTC 2024
Modified Files:
src/distrib/sets/lists/man: mi
Log Message:
sigh, no more info files for gdb.
Can we please try and find someone to package up the inf
On 10/08/2024 22:49, Taylor R Campbell wrote:
Date: Sat, 10 Aug 2024 21:37:45 +
From: Taylor R Campbell
I suggest doing the same here (and in bge(4) and in vmx(4) and
wherever else we have an overbroad `core lock'), with the attached
patch. But I don't have any awge(4) hardware to test.
On 10/08/2024 22:37, Taylor R Campbell wrote:
Module Name:src
Committed By: skrll
Date: Sat Aug 10 12:16:47 UTC 2024
Modified Files:
src/sys/arch/arm/altera: cycv_gmac.c
src/sys/arch/arm/amlogic: meson_dwmac.c
src/sys/arch/arm/rockchip: rk_gmac.c
> Date: Sat, 10 Aug 2024 21:37:45 +
> From: Taylor R Campbell
>
> I suggest doing the same here (and in bge(4) and in vmx(4) and
> wherever else we have an overbroad `core lock'), with the attached
> patch. But I don't have any awge(4) hardware to test. Could I
> trouble you to test this an
> Module Name:src
> Committed By: skrll
> Date: Sat Aug 10 12:16:47 UTC 2024
>
> Modified Files:
> src/sys/arch/arm/altera: cycv_gmac.c
> src/sys/arch/arm/amlogic: meson_dwmac.c
> src/sys/arch/arm/rockchip: rk_gmac.c
> src/sys/arch/arm/sunxi: sunxi_g
Fixed,
christos
> On Aug 4, 2024, at 6:52 PM, Valery Ushakov wrote:
>
> On Sun, Aug 04, 2024 at 13:18:01 -0400, Christos Zoulas wrote:
>
>> It should say acct_process(9), but we don't have a man page for it
>> (yet).
>
> A dangling reference is much better than the current incorrect and
> con
On Sun, Aug 04, 2024 at 13:18:01 -0400, Christos Zoulas wrote:
> It should say acct_process(9), but we don't have a man page for it
> (yet).
A dangling reference is much better than the current incorrect and
confusing wording. Please, can you fix it?
> > On Aug 4, 2024, at 1:02 PM, Valery Usha
It should say acct_process(9), but we don't have a man page for it (yet).
christos
> On Aug 4, 2024, at 1:02 PM, Valery Ushakov wrote:
>
> On Sat, Aug 03, 2024 at 19:49:06 -0400, Christos Zoulas wrote:
>
>> Modified Files:
>> src/share/man/man5: acct.5
>>
>> Log Message:
>> PR/58515: Kou
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Tue Jul 23 07:52:06 UTC 2024
>
> Modified Files:
> src/external/mit/xorg/server/drivers/xf86-video-nv: Makefile
>
> Log Message:
> xf86-video-nv: Don't fail on -Wpointer-sign with clang.
>
> Not sure why
Christos Zoulas wrote in
<20240721194847.c8c05f...@cvs.netbsd.org>:
|Module Name: src
|Committed By: christos
|Date: Sun Jul 21 19:48:47 UTC 2024
|
|Modified Files:
| src/external/historical/nawk/dist: lib.c
|
|Log Message:
|PR/58421: RVP: fix readdir on tmpfs. Upstream merge is
>> Module Name:src
>> Committed By: he
>> Date: Sun Jul 21 14:56:16 UTC 2024
>>
>> Modified Files:
>> src/etc: security
>>
>> Log Message:
>> etc/security: emit proper error message when there are dup groups.
>>
>> ...instead of erroring with "[: $grpname: unexpected oper
Date:Mon, 22 Jul 2024 00:07:34 +
From:Taylor R Campbell
Message-ID: <20240722000735.3069360...@jupiter.mumble.net>
| Nice, is there a PR for this? Should we pull it up to 10 or 9?
There are lots more sh quoting issues in /etc/security - normally they're
not a
> Module Name:src
> Committed By: he
> Date: Sun Jul 21 14:56:16 UTC 2024
>
> Modified Files:
> src/etc: security
>
> Log Message:
> etc/security: emit proper error message when there are dup groups.
>
> ...instead of erroring with "[: $grpname: unexpected operator".
Nic
In article ,
Roland Illig wrote:
>Am 10.07.2024 um 03:12 schrieb Christos Zoulas:
>
>src/tests/lib/libc/c063/t_fchmodat.c
>> -ATF_REQUIRE(st.st_mode = 0600);
>> +ATF_REQUIRE(st.st_mode == 0600);
>
>Should we do something to detect bugs like these mechanically?
>
>ATF_REQUIRE(cond) current
Am 10.07.2024 um 03:12 schrieb Christos Zoulas:
src/tests/lib/libc/c063/t_fchmodat.c
> - ATF_REQUIRE(st.st_mode = 0600);
> + ATF_REQUIRE(st.st_mode == 0600);
Should we do something to detect bugs like these mechanically?
ATF_REQUIRE(cond) currently expands to "if (!(cond))", and I guess
> Module Name:src
> Committed By: mrg
> Date: Thu Jul 4 05:59:05 UTC 2024
>
> Modified Files:
> src/sys/kern: vfs_syscalls.c
>
> Log Message:
> don't fd_putfile() if you haven't grabbed a ref already.
>
> the condition to call fd_getvnode() was changed, but the condition
On July 3, 2024 5:08:51 AM GMT+09:00, Taylor R Campbell
wrote:
>Module Name: src
>Committed By: riastradh
>Date: Tue Jul 2 20:08:51 UTC 2024
>
>Modified Files:
> src/sys/external/bsd/drm2/amdgpu: amdgpu2netbsd
>
>Log Message:
>amdgpu: Update amdgpu2netbsd to prepare for new imp
Hi,
On 2024/06/30 16:18, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Sun Jun 30 05:59:14 UTC 2024
Modified Files:
src/sys/arch/sun2/conf: GENERIC
Log Message:
sun2: GENERIC: XXX: Drop `MODULAR` and `compat_netbsd16.config`
as a w
> Module Name:src
> Committed By: riastradh
> Date: Sun Jun 30 16:35:19 UTC 2024
>
> Modified Files:
> src/sys/dev/usb: if_url.c
>
> Log Message:
> url(4): uint32_t for 32-bit hash so h>>31 becomes 0/1, not +1/-1.
That was supposed to read:
url(4): uint32_t for 32-bit ha
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Sun Jun 30 05:59:14 UTC 2024
>
> Modified Files:
> src/sys/arch/sun2/conf: GENERIC
>
> Log Message:
> sun2: GENERIC: XXX: Drop `MODULAR` and `compat_netbsd16.config`
>
> as a workaround for memory shortage. Even wit
Am 28.06.2024 um 22:45 schrieb Taylor R Campbell:
> +# It is tempting to use the make :P modifier here so that you can just
> +# write
> +#
> +#VERSION_MAP=foo.map
> +#
> +# instead of
> +#
> +#VERSION_MAP=${.CURDIR}/foo.map
> +#
> +# but it appears that :P works _only_ with literal
On Saturday, June 22, 2024 3:36:54 PM GMT+2 Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Sat Jun 22 13:36:54 UTC 2024
>
> Modified Files:
> src/external/mit/libcbor/lib: Makefile
>
> Log Message:
> libcbor: Fix make dependencies on configuration.h.
Taylor R Campbell writes:
> How is the host C++ compiler supposed to know that we are asking it to
> compile C++11 and not C++98 or C++17?
The compilation line should pass --std=c++11. Arguably, any program
that invokes a compiler and does not pass a --std is buggy. Things only
mostly work bec
> Date: Mon, 17 Jun 2024 03:01:55 +1000
> from: matthew green
>
> "David H. Gutteridge" writes:
> > Module Name:src
> > Committed By: gutteridge
> > Date: Sun Jun 16 16:03:30 UTC 2024
> >
> > tools/gcc/Makefile: force std=c++11 for GCC 12 builds
> >
> > GCC >= 11 now r
On 2024-06-16 13:01, matthew green wrote:
"David H. Gutteridge" writes:
Module Name:src
Committed By:gutteridge
Date:Sun Jun 16 16:03:30 UTC 2024
Modified Files:
src/tools/gcc: Makefile
Log Message:
tools/gcc/Makefile: force std=c++11 for GCC 12 builds
GCC >= 11 now requires
"David H. Gutteridge" writes:
> Module Name: src
> Committed By: gutteridge
> Date: Sun Jun 16 16:03:30 UTC 2024
>
> Modified Files:
> src/tools/gcc: Makefile
>
> Log Message:
> tools/gcc/Makefile: force std=c++11 for GCC 12 builds
>
> GCC >= 11 now requires C++11 to build. Impacted
Thank you, too, for clarification!
rin
On 2024/06/13 5:10, Nick Hudson wrote:
Thanks for the fix.
The bug affects enable and disable in the all (-1) indexes case and
references out of bounds data.
Nick
On 12/06/2024 08:36, Rin Okuyama wrote:
Hmm, there was a confusion for my side.
This bug
Thanks for the fix.
The bug affects enable and disable in the all (-1) indexes case and
references out of bounds data.
Nick
On 12/06/2024 08:36, Rin Okuyama wrote:
Hmm, there was a confusion for my side.
This bug affected cases where
(1) index >= 1 is explicitly specified for
fdtbus_powerdom
Hmm, there was a confusion for my side.
This bug affected cases where
(1) index >= 1 is explicitly specified for
fdtbus_powerdomain_enable_index(),
as well as
(2) all indices are implicitly specified by
fdtbus_powerdomain_enable().
s/enable/disable/ functions were affected also.
Thanks,
rin
> Date: Sat, 8 Jun 2024 11:51:43 +0200
> From: Roland Illig
>
> Am 07.06.2024 um 22:50 schrieb Taylor R Campbell:
> > libc: Pacify lint on aarch64.
> >
> > +++ src/lib/libc/stdlib/Makefile.incFri Jun 7 20:50:13 2024
> > +# lint(1) spuriously complains about `*s == CHAR_MAX' even though *
On 2024/06/04 7:41, Christos Zoulas wrote:
In article <20240603184723.c745cf...@cvs.netbsd.org>,
Taylor R Campbell wrote:
-=-=-=-=-=-
Module Name:src
Committed By: riastradh
Date: Mon Jun 3 18:47:23 UTC 2024
Modified Files:
src/distrib/sets/lists/base32: ad.aarch64 md
Am 07.06.2024 um 22:50 schrieb Taylor R Campbell:
> libc: Pacify lint on aarch64.
>
> +++ src/lib/libc/stdlib/Makefile.inc Fri Jun 7 20:50:13 2024
> +# lint(1) spuriously complains about `*s == CHAR_MAX' even though *s
> +# has type char.
> +LINTFLAGS.strfmon.c += -X 230
I guess the "spuriously"
In article <20240603184723.c745cf...@cvs.netbsd.org>,
Taylor R Campbell wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: riastradh
>Date: Mon Jun 3 18:47:23 UTC 2024
>
>Modified Files:
> src/distrib/sets/lists/base32: ad.aarch64 md.sparc64
> src/distrib/sets/lists/co
Hi,
Thanks for your fix.
It works fine for me.
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Sat May 25 13:44:48 UTC 2024
>
> Modified Files:
> src/sys/sys: ucontext.h
>
> Log Message:
> ucontext.h: Expose __UCONTEXT_SIZE to userland.
>
> But do
> Your diff is backwards and I guess that is the cause for the confusion.
Ah, I checked a wrong tree. Sorry for the noise.
---
Izumi Tsutsui
On Sat, Jun 01, 2024 at 11:17:11PM +0900, Izumi Tsutsui wrote:
> > Log Message:
> > Fix typo in previous
>
> ---
> @@ -1126,7 +1126,7 @@ copymodes(int fd, const struct stat *sbp
> if (fchmod(fd, sb.st_mode) < 0)
> maybe_warn("couldn't fchmod: %s", file);
>
> -#if !HAVE_NBTOOL
martin@ wrote:
> Module Name: src
> Committed By: martin
> Date: Sat Jun 1 10:17:12 UTC 2024
>
> Modified Files:
> src/usr.bin/gzip: gzip.c
>
> Log Message:
> Fix typo in previous
---
@@ -1126,7 +1126,7 @@ copymodes(int fd, const struct stat *sbp
if (fchmod(fd, sb.st_mod
What issue is this change attempting to resolve?
> On May 20, 2024, at 4:34 AM, Taylor R Campbell wrote:
>
> Module Name: src
> Committed By: riastradh
> Date: Mon May 20 11:34:19 UTC 2024
>
> Modified Files:
> src/sys/arch/sparc64/dev: pci_machdep.c
> src/sys/arch/sparc64/include: pci_machdep.
Taylor R Campbell wrote:
> Can you please back this out promptly, add automatic tests for
> whatever the underlying issue is, and redo it another way?
I did a scan of miss-use of <>, and looks like libc might
have an issue:
lib/libc/arch/arm/Makefile.inc:28:.include
expects to find lib/libc/so
thanks for this fix.
> Modified Files:
> src/external/gpl3/gcc/dist/libstdc++-v3/config/io: basic_file_stdio.cc
probably want to apply this fix to gcc.old, and also consider
pullup-10 (and pullup-9, if similar?), since gcc.old is the
currently used compiler in current.
.mrg.
Taylor R Campbell wrote:
>
> --- cleandir-libterminfo ---
> nbmake[5]: "/tmp/build/2024.05.19.20.09.40-i386/src/lib/libterminfo/Makefile"
> line 50: Could not find Makefile.hash
>
> Can you please back this out promptly, add automatic tests for
> whatever the underlying issue is, and redo it an
> Module Name:src
> Committed By: sjg
> Date: Sun May 19 20:09:40 UTC 2024
>
> Modified Files:
> src/usr.bin/make: dir.c dir.h parse.c
>
> Log Message:
> make: use separate function to include makefiles.
>
> Have Dir_FindFile and Dir_FindInclude call FindFile with a
> boo
> On May 19, 2024, at 6:21 PM, Christos Zoulas wrote:
>
> We discussed it with Taylor and decided to call it dup3100 after all since
> we've
> already followed the old scheme for kevent100 and it is better to be
> consistent
> for the 11 release.We can start calling new syscalls 12 after 11
> On May 19, 2024, at 9:19 PM, Jason Thorpe wrote:
>
>
>> On May 19, 2024, at 5:35 PM, Christos Zoulas wrote:
>>
>> In article <9c72736d-707b-4267-bd05-45bffea52...@me.com>,
>> Jason Thorpe wrote:
>>>
>>>
On May 19, 2024, at 3:25 PM, Christos Zoulas wrote:
src/sys/compa
> On May 19, 2024, at 5:35 PM, Christos Zoulas wrote:
>
> In article <9c72736d-707b-4267-bd05-45bffea52...@me.com>,
> Jason Thorpe wrote:
>>
>>
>>> On May 19, 2024, at 3:25 PM, Christos Zoulas wrote:
>>>
>>> src/sys/compat/common: compat_110_mod.c sys_decrip_110.c
>>> src/sys/compat/netbs
In article <9c72736d-707b-4267-bd05-45bffea52...@me.com>,
Jason Thorpe wrote:
>
>
>> On May 19, 2024, at 3:25â¯PM, Christos Zoulas wrote:
>>
>> src/sys/compat/common: compat_110_mod.c sys_decrip_110.c
>> src/sys/compat/netbsd32: netbsd32_compat_110.c
>> src/sys/conf: compat_netbsd110.config
>>
> On May 19, 2024, at 3:25 PM, Christos Zoulas wrote:
>
> src/sys/compat/common: compat_110_mod.c sys_decrip_110.c
> src/sys/compat/netbsd32: netbsd32_compat_110.c
> src/sys/conf: compat_netbsd110.config
> src/sys/modules/compat_110: Makefile
> src/sys/modules/compat_netbsd32_110: Makefile
Wa
On Thu, May 16, 2024 at 05:48:05PM +0300, Valery Ushakov wrote:
> On Thu, May 16, 2024 at 11:54:20 +, Nia Alarie wrote:
>
> > Modified Files:
> > src/share/man/man4: eap.4
> >
> > Log Message:
> > Note that EAP_USE_BOTH_DACS is deprecated in the eap(4) manual page.
>
> Please, can you re
On Thu, May 16, 2024 at 11:54:20 +, Nia Alarie wrote:
> Modified Files:
> src/share/man/man4: eap.4
>
> Log Message:
> Note that EAP_USE_BOTH_DACS is deprecated in the eap(4) manual page.
Please, can you restore the part that explains what this option
is/does? It might be on its way o
Date:Wed, 15 May 2024 02:33:23 +0300
From:Valery Ushakov
Message-ID:
| I vaguely remember I read somewhere that printf(1) was specifically
| conceived to take no options, but that can be planted memories. May
| be it's indeed induced by the old state of affair
On Wed, May 15, 2024 at 05:22:25 +0700, Robert Elz wrote:
> | Unfortunately that advice is not true without further caveats.
>
> That you have to actually write a valid printf(1) command, and not
> simply s/echo/printf/ ? Does that really need saying?
>
>
> | netbsd$ sh -c "printf '-V\n'"
Date:Tue, 14 May 2024 12:41:51 +0300
From:Valery Ushakov
Message-ID:
| Unfortunately that advice is not true without further caveats.
That you have to actually write a valid printf(1) command, and not
simply s/echo/printf/ ? Does that really need saying?
| n
On Tue, May 14, 2024 at 01:32:25 +, David H. Gutteridge wrote:
> Log Message:
> echo.1: borrow advice about printf(1) from the OpenBSD man page
Unfortunately that advice is not true without further caveats.
netbsd$ sh -c "printf '-V\n'"
-V
$ busybox sh -c "printf '-V\n'"
-V
ubuntu$ $ dash
Am 13.05.2024 um 16:06 schrieb Taylor R Campbell:
>> Module Name:src
>> Committed By: rillig
>> Date: Sun May 12 19:03:55 UTC 2024
>>
>> Modified Files:
>> src/usr.sbin/flashctl: flashctl.c
>>
>> Log Message:
>> flashctl: fix lint's strict bool mode with Clang preprocessor
>
> Module Name:src
> Committed By: rillig
> Date: Sun May 12 19:03:55 UTC 2024
>
> Modified Files:
> src/usr.sbin/flashctl: flashctl.c
>
> Log Message:
> flashctl: fix lint's strict bool mode with Clang preprocessor
>
> Treating the return value from the character classif
Date:Thu, 9 May 2024 17:44:16 -0400
From:Christos Zoulas
Message-ID: <9c618434-9d7b-4f1c-97ed-3260b7f36...@zoulas.com>
| I am not sure either but the resulting cd does not boot anymore.
Which version? It has been a long time since I needed to boot
from an optical
> On May 9, 2024, at 5:37 PM, Robert Elz wrote:
>
> Date:Thu, 9 May 2024 12:09:03 -0400
>From:"Christos Zoulas"
>Message-ID: <20240509160903.6e41bf...@cvs.netbsd.org>
>
> | Instead of augmenting the platform spec with an autogenerated one,
> | we should unders
Date:Thu, 9 May 2024 12:09:03 -0400
From:"Christos Zoulas"
Message-ID: <20240509160903.6e41bf...@cvs.netbsd.org>
| Instead of augmenting the platform spec with an autogenerated one,
| we should understand why we have missing entries in the first place.
Is it real
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Sun May 5 15:25:31 UTC 2024
>
> Modified Files:
> src/external/mit/xorg/lib/dri: Makefile
> src/external/mit/xorg/lib/dri.old: Makefile
>
> Log Message:
> mesa: Build with -Wno-error=typedef-redef
> On May 3, 2024, at 11:11 AM, Roland Illig wrote:
>
> Am 02.05.2024 um 22:44 schrieb Christos Zoulas:
>> On 2024-05-02 3:04 pm, Christos Zoulas wrote:
>>> This is with clang.
>>>
>> And I don't get it. Gcc produces:
>>
>> if (ignore &&
>> # 139 "base64.c" 3 4
>>((int)((_ct
Am 02.05.2024 um 22:44 schrieb Christos Zoulas:
> On 2024-05-02 3:04 pm, Christos Zoulas wrote:
>> This is with clang.
>>
> And I don't get it. Gcc produces:
>
>if (ignore &&
> # 139 "base64.c" 3 4
> ((int)((_ctype_tab_ + 1)[(
> # 139 "base64.c"
> c
> # 139 "base
On 2024-05-02 3:04 pm, Christos Zoulas wrote:
On 2024-05-02 2:47 pm, Roland Illig wrote:
Am 02.05.2024 um 17:45 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Thu May 2 15:45:36 UTC 2024
Modified Files:
src/usr.bin/base64: Makefile
Log Message:
> Date: Thu, 2 May 2024 21:04:38 +0200
> From: Roland Illig
>
> Am 02.05.2024 um 05:30 schrieb Robert Elz:
> > Use intmax_t instead of long int when trying to represent very large
> > integers (10^50 or so), so we don't exceed the capacity of systems where
> > long int is only 32 bits.
>
> I par
On 2024-05-02 2:47 pm, Roland Illig wrote:
Am 02.05.2024 um 17:45 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Thu May 2 15:45:36 UTC 2024
Modified Files:
src/usr.bin/base64: Makefile
Log Message:
comment out strict boolean lint check because i
Am 02.05.2024 um 05:30 schrieb Robert Elz:
> Module Name: src
> Committed By: kre
> Date: Thu May 2 03:30:07 UTC 2024
>
> Modified Files:
> src/tests/lib/libm: t_fe_round.c
>
> Log Message:
> Use intmax_t instead of long int when trying to represent very large
> integers (10^50 or s
Am 02.05.2024 um 17:45 schrieb Christos Zoulas:
> Module Name: src
> Committed By: christos
> Date: Thu May 2 15:45:36 UTC 2024
>
> Modified Files:
> src/usr.bin/base64: Makefile
>
> Log Message:
> comment out strict boolean lint check because isspace() returns int and lint
> compla
And yes, I know, it should have been 2^50 not 10^50...
kre
Date:Wed, 1 May 2024 22:27:02 +0200
From:Roland Illig
Message-ID: <754bd755-be0a-4eff-aa7b-d53fce9b4...@gmx.de>
| > Log Message:
| > next should increement by 1 not 2.
|
| Are you sure?
I agree, that change should be reverted.
"next" is even documented to be
1 - 100 of 1062 matches
Mail list logo