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:
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
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
> 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
>
> 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:
> 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
>>>
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
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
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
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
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
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?
|
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
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
> 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
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
"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
> 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
>>
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
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
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
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
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
>
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
Am 01.05.2024 um 21:59 schrieb Christos Zoulas:
> Module Name: src
> Committed By: christos
> Date: Wed May 1 19:59:08 UTC 2024
>
> Modified Files:
> src/lib/libutil: parsedate.y
>
> Log Message:
> next should increement by 1 not 2.
Are you sure? I get these test results:
>
Am 30.04.2024 um 11:55 schrieb Izumi Tsutsui:
> Module Name: src
> Committed By: tsutsui
> Date: Tue Apr 30 09:55:46 UTC 2024
>
> Modified Files:
> src/sys/arch/hp300/dev: dma.c
>
> Log Message:
> Fix another fatal typo that prevents dma(4) interrupts.
The buggy code was:
>
> Module Name:src
> Committed By: christos
> Date: Fri Apr 26 18:19:18 UTC 2024
>
> Modified Files:
> src/sys/dev/acpi: acpi_bat.c
>
> Log Message:
> PR/58201: Malte Dehling: re-order sysmon initialization before acpi
> registration, to avoid needing to call to
On Fri, Apr 19, 2024 at 10:48:10PM +0700, Robert Elz wrote:
> Date:Fri, 19 Apr 2024 14:58:18 +
> From:"Jonathan A. Kollasch"
> Message-ID: <20240419145818.351d2f...@cvs.netbsd.org>
>
> | - bail out if resulting __DATE__/__TIME__ replacement strings are empty
>
Date:Fri, 19 Apr 2024 14:58:18 +
From:"Jonathan A. Kollasch"
Message-ID: <20240419145818.351d2f...@cvs.netbsd.org>
| - bail out if resulting __DATE__/__TIME__ replacement strings are empty
If you want to do that (not that it would be useful, even if the %b
On Fri 19 Apr 2024 at 14:47:23 +0200, Martin Husemann wrote:
> The problem (IIUC) is that the ntp code parses this value internally, so
> it won't talk to anyone claiming a time before the time ntpd was compiled
> (or something along that line).
Would it make sense to just supply a fixed string
Date:Fri, 19 Apr 2024 14:57:46 +0200
From:Martin Husemann
Message-ID: <20240419125746.gb26...@mail.duskware.de>
| On Fri, Apr 19, 2024 at 02:47:23PM +0200, Martin Husemann wrote:
| > The commit message could have explained that a bit.
|
| And it actually
On Fri, Apr 19, 2024 at 02:47:23PM +0200, Martin Husemann wrote:
> The commit message could have explained that a bit.
And it actually should have been "+%b %e %Y" - from the C18 standard draft:
6.10.8.1 Mandatory macros
__DATE__
The date of translation of the preprocessing translation unit:
On Fri, Apr 19, 2024 at 04:36:46PM +0700, Robert Elz wrote:
> I don't understand that change, it altered from
>
> MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%F"
> to
> MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%b %d %Y"
>
> %F is simply a shorthand
Date:Thu, 18 Apr 2024 19:23:54 +
From:"Jonathan A. Kollasch"
Message-ID: <20240418192354.1bcc1f...@cvs.netbsd.org>
| Module Name:src
| Committed By: jakllsch
| Date: Thu Apr 18 19:23:54 UTC 2024
|
| Modified Files:
|
maya@ wrote:
> Module Name: src
> Committed By: maya
> Date: Tue Apr 16 16:13:45 UTC 2024
>
> Modified Files:
> src/distrib/amd64/liveimage/emuimage: Makefile rc.conf.emuimage
> spec.emuimage
>
> Log Message:
> restore amd64 live image support for resize root after
> And also slightly related: we need a way to mark directories as
> optional in the mtree files (or have a way to provide several
> alternative options). Typical issue: /var/shm is a symlink on most
> of my smaller machines, but it is impossible to make such setups pass
> the mtree tests.
Maybe
On Thu, Apr 11, 2024 at 01:06:10PM +, Taylor R Campbell wrote:
> I agree, this is related to the subject of, and could probably use the
> same mechanism as, PR 57581: set lists should have a way to obsolete
> shlibs in DESTDIR but not in postinstall.
>
> https://gnats.NetBSD.org/57581
And
> Date: Thu, 11 Apr 2024 11:19:38 +0700
> From: Robert Elz
>
> This is why I'd like to add a new keyword in the sets lists, like
> "obsolete" is - probably "optional" to mark files that aren't installed
> by the build, but might exist, and should simply be ignored if
> found - it isn't an error
Hi,
Periodic snapshot build fails for (probably) all platforms with
MKCOMPAT enabled:
http://releng.netbsd.org/builds/HEAD/202404101150Z/
Please take a look. And more importantly, careful tests are
always appreciated before commit. To be fair, there are tons of
combinations of mk.conf
Date:Thu, 11 Apr 2024 02:15:39 +
From:"Taylor R Campbell"
Message-ID: <20240411021539.a3272f...@cvs.netbsd.org>
| However, this means that update builds need manual intervention to
| delete $DESTDIR/var/run/named or else checkflist will fail, so add a
|
On Mon, Apr 08, 2024 at 23:31:16 +0200, Roland Illig wrote:
> Am 08.04.2024 um 21:18 schrieb Valery Ushakov:
> > "=\017FIFTEEN\0"
> >
> > with its result a few lines below that has:
> >
> > BURST=0xf=FIFTEEN
>
> Thank you for explaining this example. I had a gut feeling that there
> would be
Am 08.04.2024 um 21:18 schrieb Valery Ushakov:
> "=\017FIFTEEN\0"
>
> with its result a few lines below that has:
>
> BURST=0xf=FIFTEEN
Thank you for explaining this example. I had a gut feeling that there
would be some hidden correlation between some octal/hexadecimal
combinations, but I
On Mon, Apr 08, 2024 at 20:21:07 +0200, Roland Illig wrote:
> I didn't eradicate _all_ hexadecimal examples, I just made each example
> use only one number base, not mix them both. There are both octal and
> hexadecimal examples in the manual page.
That's not what "prefer octal in examples"
Am 08.04.2024 um 03:24 schrieb Valery Ushakov:
> On Sun, Apr 07, 2024 at 14:28:27 +, Roland Illig wrote:
>
>> Log Message:
>> snprintb.3: clean up formatting and wording, prefer octal in examples
>>
>> Using hexadecimal character escapes requires separate string literals if
>> the description
Hi,
It's likely minor, but I believe these changes are enough to also
update the documentation date:
Index: ./src/sbin/ifconfig/ifconfig.8
-.Dd November 25, 2022
+.Dd April 8, 2024
Also "If the interface id a lagg(4) pseudo-interface" probably was
meant to be "If the interface is a lagg(4)..."
On Sun, Apr 07, 2024 at 14:28:27 +, Roland Illig wrote:
> Log Message:
> snprintb.3: clean up formatting and wording, prefer octal in examples
>
> Using hexadecimal character escapes requires separate string literals if
> the description starts with one of the letters A-F; octal character
>
In article <20240405085127.b998ef...@cvs.netbsd.org>,
Robert Elz wrote:
>Module Name: src
>Committed By: kre
>Date: Fri Apr 5 08:51:27 UTC 2024
>
>Modified Files:
> src/external: Makefile
> src/external/mit/libuv/lib: Makefile
>
>Log Message:
>Probable hack fix for
Date:Fri, 5 Apr 2024 08:51:27 +
From:"Robert Elz"
Message-ID: <20240405085127.b998ef...@cvs.netbsd.org>
Christos, this seems to fix the builds, but I doubt it is really
done correctly (and I don't just mean the overlong line I left in
src/external/Makefile which
On Sat, Mar 30, 2024 at 23:20:38 -0400, Christos Zoulas wrote:
> Restore the minimum build to install elfdefinitions.h. Provide a pre-built
> copy, since we don't have m4 available. Use pax to install it because
> using the Makefile needs more stuff available (nbsed) which we have not
> built
On Sun, Mar 24, 2024 at 21:21:39 +0200, Andrius V wrote:
> Can you a bit clarify the meaning of "8 space tabs"
This is what VT set up screen called "Set 8 Column Tabs", i.e. "set
one tab every eight columns, starting at column 9" which was the
default setting.
Hi,
Can you a bit clarify the meaning of "8 space tabs", since file is not
exactly following any completely defined pattern. Should I use tabs
before multiline comment text (*^I^I) and align
text between routine name and description, also remove all unnecessary
whitespace characters? Attached
On Sat, Mar 23, 2024 at 21:10:45 +, Andrius Varanavicius wrote:
> Modified Files:
> src/games/larn: io.c
>
> Log Message:
> Attempt to fix descriptions of the routines in the initial comment block.
Please, can you fix this to use 8 space tabs as the rest of the file
does, as can be
Am 14.03.2024 um 21:27 schrieb Robert Elz:
> Date:Thu, 14 Mar 2024 20:53:13 +0100
> From:Roland Illig
> Message-ID: <9c7513f7-97b5-4d3b-9d66-dce483af7...@gmx.de>
>
> | I don't think the flags '+' and '0' make sense for strings, that's why I
> | decided to preserve
Date:Thu, 14 Mar 2024 20:53:13 +0100
From:Roland Illig
Message-ID: <9c7513f7-97b5-4d3b-9d66-dce483af7...@gmx.de>
| I don't think the flags '+' and '0' make sense for strings, that's why I
| decided to preserve existing behavior.
But the change only affected
Am 14.03.2024 um 20:38 schrieb Robert Elz:
> Module Name: src
> Committed By: kre
> Date: Thu Mar 14 19:38:56 UTC 2024
>
> Modified Files:
> src/usr.bin/stat: stat.c
>
> Log Message:
> While the change in 1.51 certainly retained binary compat with
> what was in 1.50 (while silencing
Thanks, should take remember this for the future reference.
On Wed, Mar 13, 2024 at 8:59 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Mar 13 06:59:01 UTC 2024
>
> Modified Files:
> src/sys/arch/evbmips/evbmips: interrupt.c
>
> Log Message:
>
Hi,
"matthew green" writes:
> Module Name: src
> Committed By: mrg
> Date: Thu Feb 22 02:47:27 UTC 2024
>
> Modified Files:
> src/tools/gcc: Makefile
>
> Log Message:
> enable isl support for GCC 12.
I have HAVE_GCC=12 in my /etc/mk.conf.
I have gotten the following error.
In article <20240218223315.800aff...@cvs.netbsd.org>,
Thomas Klausner wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: wiz
>Date: Sun Feb 18 22:33:15 UTC 2024
>
>Modified Files:
> src/usr.bin/ftp: ftp_var.h
>
>Log Message:
>ftp: bump FTPBUFLEN from 4kB to 16kB
>
I made it return EPERM if they are different.
christos
> On Feb 3, 2024, at 3:58 PM, J. Hannken-Illjes wrote:
>
>> On 3. Feb 2024, at 19:45, Christos Zoulas wrote:
>>
>> Oh, I fixed GETARGS, but not UPDATE... How about now?
>
> What is the expected result if we update a cd9660 mount with
> On 3. Feb 2024, at 19:45, Christos Zoulas wrote:
>
> Oh, I fixed GETARGS, but not UPDATE... How about now?
What is the expected result if we update a cd9660 mount with different
uid/gid or masks?
If it is forbidden the "mp->mnt_flag & MNT_UPDATE" case, lines 306 .. 312
of cd9660_vfsops.c
Oh, I fixed GETARGS, but not UPDATE... How about now?
christos
> On Feb 3, 2024, at 12:48 PM, J. Hannken-Illjes wrote:
>
>> On 3. Feb 2024, at 18:38, Christos Zoulas wrote:
>>
>> Fixed, thanks.
>
> Not really, with "struct iso_args *args = data" you cannot set fields
> beyond "datalen" here
> On 3. Feb 2024, at 18:38, Christos Zoulas wrote:
>
> Fixed, thanks.
Not really, with "struct iso_args *args = data" you cannot set fields
beyond "datalen" here and the MNT_UPDATE case is still missing.
--
J. Hannken-Illjes - hann...@mailbox.org
Fixed, thanks.
christos
> On 2. Feb 2024, at 21:27, Christos Zoulas wrote:
>
> Module Name: src
> Committed By: christos
> Date: Fri Feb 2 20:27:26 UTC 2024
>
> Modified Files:
> src/sbin/mount_cd9660: Makefile mount_cd9660.8 mount_cd9660.c
> src/sys/fs/cd9660: cd9660_extern.h cd9660_mount.h cd9660_vfsops.c
>
"Taylor R Campbell" writes:
> Mark /var/run/named obsolete in the set lists. XXX This isn't quite
> right, because it is legitimate for /var/run/named to exist in a
> running installation, but it doesn't exist in a freshly installed
> system any more. Maybe we should just remove the entry from
On Thu, 25 Jan 2024 20:02:00 +0100, Roland Illig writes:
>>> Modified Files:
>>> src/usr.bin/make: make.1
>>>
>>> Log Message:
>>> Indicate that for :U newval is optional
>>
>> I think this is more confusing than helpful.
>
>I agree. Make doesn't distinguish between an empty string and an
On Thu, 25 Jan 2024 21:12:20 +0100, Roland Illig writes:
>them all. Due to this, I'd go with:
>
>> .It Cm \&:U\| Ns Ar newval
>> If the variable is undefined,
>> .Ar newval
>> (which may be empty) is the value.
That's almost exactly what I had in my 1st cut ;-)
Will do.
>Then, add the same
About optional arguments to modifiers, such as in ${VAR:U}:
Am 25.01.2024 um 20:54 schrieb Simon Gerraty:
> Is there perhaps a general statement somewhere (I may have missed it)
> that could cover all these and be cited to pedantic users?
> Eg to the effect of perhaps, unless stated otherwise
Am 25.01.2024 um 14:25 schrieb Valery Ushakov:
> On Thu, Jan 25, 2024 at 07:35:46 +, Simon J. Gerraty wrote:
>
>> Modified Files:
>> src/usr.bin/make: make.1
>>
>> Log Message:
>> Indicate that for :U newval is optional
>
> I think this is more confusing than helpful.
I agree. Make
In article <19118.1705868...@jacaranda.noi.kre.to>,
Robert Elz wrote:
>Date:Sun, 21 Jan 2024 18:16:28 - (UTC)
>From:chris...@astron.com (Christos Zoulas)
>Message-ID:
>
> | I think this is the yacc used by the build process, not the yacc
> | to build tools
On Sun, Jan 21, 2024 at 21:31:23 +, Roland Illig wrote:
> and also didn't make it clear that a few bits were omitted from
> having descriptions.
I dislike this part. It's internally inconsistent as it doesn't add
the placeholders for the low bits; and in many real-life scenarios
there will
Date:Sun, 21 Jan 2024 18:16:28 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| I think this is the yacc used by the build process, not the yacc
| to build tools with? I.e. will this yacc produce c files usable in
| the host compilation
Am 21.01.2024 um 19:16 schrieb Christos Zoulas:
> In article ,
> Valery Ushakov wrote:
>> On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote:
>>
>>> Consider providing parsedate(3) in libcompat, but then we'd need
>>> yacc...
>>
>> We already have yacc in tools - src/tools/yacc
>
> I
In article ,
Valery Ushakov wrote:
>On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote:
>
>> Consider providing parsedate(3) in libcompat, but then we'd need
>> yacc...
>
>We already have yacc in tools - src/tools/yacc
I think this is the yacc used by the build process, not the yacc
On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote:
> Consider providing parsedate(3) in libcompat, but then we'd need
> yacc...
We already have yacc in tools - src/tools/yacc
-uwe
On Thu, Jan 18, 2024 at 06:43:21 +1100, matthew green wrote:
> > Log Message:
> > macppc: enable FFS_EI in GENERIC
> >
> > I'd say it should be enabled for anything with USB.
> >
> > ok macallan
>
> yay. i think we should enable it basically everywhere that it
> is not a space issue.
I think
> Log Message:
> macppc: enable FFS_EI in GENERIC
>
> I'd say it should be enabled for anything with USB.
>
> ok macallan
yay. i think we should enable it basically everywhere that it
is not a space issue. USB is just one common way, but i can
also modify or create my own images anyway, and
> No, that definitely wasn't intentional! I've just reverted
> that. Does that need a pullup for netbsd-10 ?
Thanks for your confirmation.
I have another fix to make GENERIC boot on my 3/60
(disable more several pseudo-devices to shrink binary)
so I'll handle a pullup request with your fix.
Hi Tsutsui,
Izumi Tsutsui wrote:
> simonb@ wrote:
>
> > cvs rdiff -u -r1.187 -r1.188 src/sys/arch/sun3/conf/GENERIC
>
> >> # Veriexec
> >> # include "dev/veriexec.config"
> >> +
> >> +no obmem0 at mainbus? # XX
>
> Is this intentional!?
No, that definitely wasn't
simonb@ wrote:
> Module Name: src
> Committed By: simonb
> Date: Sun Aug 7 02:52:30 UTC 2022
>
> Modified Files:
:
> src/sys/arch/sun3/conf: DISKLESS GENERIC GENERIC3X
:
> Log Message:
> UFS/LFS dirhash:
> - Enable UFS_DIRHASH if the architecture or kernel model specific config
In article <2017973.usquhbg...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Jan 2 19:27:57 UTC 2024
>>
>> Modified Files:
>> src/sys/sys:
I would also prefer current general "virt68k", rather than
specific emulators like qemu68k etc. because:
- it's unlikely that someone will design and implement new virtual
Ethernet/storage I/O devices for ancient architectures
- we should avoid dumb copies of MD locore.s, pmap_bootstrap.c,
> On Jan 3, 2024, at 9:16 AM, Jason Thorpe wrote:
>
> There’s really nothing Qemu specific about it, other than Qemu version number
> extraction.
Let me elaborate, actually, now that I am not constrained by thumbs-only typing.
It uses the generic Linux m68k “bootinfo”, which specify the
There’s really nothing Qemu specific about it, other than Qemu version number
extraction.
-- thorpej
Sent from my iPhone.
> On Jan 2, 2024, at 11:03 PM, Valery Ushakov wrote:
>
> On Wed, Jan 03, 2024 at 02:48:06 +, Jason R Thorpe wrote:
>
>> Add virt68k to MACHINES.m68k.
>
> "virt" is
On Wed, Jan 03, 2024 at 02:48:06 +, Jason R Thorpe wrote:
> Add virt68k to MACHINES.m68k.
"virt" is too generic a name, if this is specifically a qemu version,
may be it should have been called qemu68k... Guess it's too late now.
-uwe
Date:Tue, 2 Jan 2024 21:20:42 -0500
From:Jason Thorpe
Message-ID:
| seems safe
Safe probably, but also wrong. It looks to be there puerly
for the __BEGIN_DECLS / __END_DECLS definitions - which are
needed just beause has prototypes for lseek()
truncate() and
> On Jan 2, 2024, at 8:41 PM, Robert Elz wrote:
>
> I doubt that should really be including
> and almost certainly not , and shouldn't have prototypes
> for any functions at all.
seems safe — all of that stuff is in the implementation namespace.
-- thorpej
Date:Wed, 3 Jan 2024 03:15:39 +0300
From:Valery Ushakov
Message-ID:
| for userland uses should include stddef.h where size_t is supposed
| to come from
Unfortunately, while is defined to specify size_t it
isn't specified to include ssize_t - and many things
On Wed, Jan 03, 2024 at 01:06:57 +0100, Joerg Sonnenberger wrote:
> Date: Wed, 03 Jan 2024 01:06:57 +0100
> From: Joerg Sonnenberger
> Subject: Re: CVS commit: src/sys/sys
> To: source-changes-d@netbsd.org
>
> On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrot
On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Jan 2 19:27:57 UTC 2024
>
> Modified Files:
> src/sys/sys: rbtree.h
>
> Log Message:
> This uses size_t, so it always needs , remove ifdefs.
sys/types.h is
On Thu, Dec 28, 2023 at 11:08 PM Robert Elz wrote:
>
> [I could claim that the typo was deliberate, as part of
> the test but that would be kind of absurd, sh does
> no spell checking to test.]
>
> kre
>
Thanks for clarification. I definitely had few instances when I needed
to revert
Date:Thu, 28 Dec 2023 20:04:11 +
From:"Andrius Varanavicius"
Message-ID: <20231228200411.283ccf...@cvs.netbsd.org>
| Modified Files:
| src/tests/bin/sh: t_syntax.sh
| Log Message:
| s/synax/syntax/ in test description.
Thanks for the correction, but,
"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Tue Dec 19 07:05:36 UTC 2023
>
> Modified Files:
> src/sys/dev/usb: if_axen.c
>
> Log Message:
> Add support for AX88179A. From sc.dying on current-users.
>
>
> To generate a diff of this commit:
> cvs rdiff -u
1 - 100 of 11269 matches
Mail list logo
