Updating src tree:
P src/Makefile
P src/distrib/sets/lists/base/md.i386
P src/distrib/sets/lists/base/shl.mi
P src/distrib/sets/lists/comp/mi
P src/distrib/sets/lists/comp/shl.mi
P src/distrib/sets/lists/debug/mi
P src/distrib/sets/lists/debug/shl.mi
P src/distrib/sets/lists/man/mi
P
Date:Fri, 23 Aug 2019 20:52:02 +0200
From:Martin Husemann
Message-ID: <20190823185202.ga3...@mail.duskware.de>
| On Fri, Aug 23, 2019 at 07:30:33PM +0100, Robert Swindells wrote:
| > Someone using a disk with 4k blocks might want
|
| If we *have* to set that
How are people supposed to set the block and fragment sizes in the NetBSD
installer? If it's still possible, it certainly isn't easy to find.
Is it usefull anywhere?
I removed it, thinking noone would care. If there is use for it, I'll re-add
it to the partition details menu:
It would go
On Fri, Aug 23, 2019 at 07:30:33PM +0100, Robert Swindells wrote:
> >But is it really needed?
>
> Someone using a disk with 4k blocks might want to set the fragment size
> to that and the block size to a multiple.
If we *have* to set that manually, something is wrong.
Besides, only disklabel
Martin Husemann wrote:
>On Fri, Aug 23, 2019 at 06:13:30PM +, John Klos wrote:
>> How are people supposed to set the block and fragment sizes in the NetBSD
>> installer? If it's still possible, it certainly isn't easy to find.
>
>Is it usefull anywhere?
What do they default to ?
>But is
On Fri, Aug 23, 2019 at 06:13:30PM +, John Klos wrote:
> How are people supposed to set the block and fragment sizes in the NetBSD
> installer? If it's still possible, it certainly isn't easy to find.
Is it usefull anywhere?
I removed it, thinking noone would care. If there is use for it,
How are people supposed to set the block and fragment sizes in the NetBSD
installer? If it's still possible, it certainly isn't easy to find.
John
On 23.08.2019 16:10, Thomas Klausner wrote:
> On Fri, Aug 23, 2019 at 04:03:01PM +0200, Kamil Rytarowski wrote:
>> On 23.08.2019 11:41, Thomas Klausner wrote:
>>> With a cvs checkout from about an our ago, an amd64 build failed for
>>> me:
>>>
>>> --- dependall-safestack-m32 ---
>>>
On Fri, Aug 23, 2019 at 04:03:01PM +0200, Kamil Rytarowski wrote:
> On 23.08.2019 11:41, Thomas Klausner wrote:
> > With a cvs checkout from about an our ago, an amd64 build failed for
> > me:
> >
> > --- dependall-safestack-m32 ---
> >
On 23.08.2019 11:41, Thomas Klausner wrote:
> With a cvs checkout from about an our ago, an amd64 build failed for
> me:
>
> --- dependall-safestack-m32 ---
> /usr/src/sys/external/bsd/compiler_rt/dist/lib/safestack/safestack.cc:271:23:
> error: constructor priorities from 0 to 100 are reserved
On Fri, Aug 23, 2019 at 09:56:47AM +0200, Frank Kardel wrote:
> And what mechanisms does NPF provide to access the broadcast address except
> for manually coding it - did I overlook something?
Since we can do inet4(),inet6() or ifaddrs() we can probably
add ifmask4() or ifmask6(). But we can
With a cvs checkout from about an our ago, an amd64 build failed for
me:
--- dependall-safestack-m32 ---
/usr/src/sys/external/bsd/compiler_rt/dist/lib/safestack/safestack.cc:271:23:
error: constructor priorities from 0 to 100 are reserved for the implementation
[-Werror]
void
On 08/22/19 17:44, Michael van Elst wrote:
On Thu, Aug 22, 2019 at 04:02:43PM +0200, Frank Kardel wrote:
I found that in the mean time - thanks for looking.
That leaves me probably with no generic way in npf to detect/determine
broadcast addresses.
NPF does not seem to have PF's
13 matches
Mail list logo
