Michael McConville wrote:
> Diff below. Is anyone running an NFS server on -current willing to
> test?
Disregard, this needs more initial testing (by me) first. It's hanging
when registering the service.
> Index: mountd.c
> ===
> RCS
The two most recent diffs here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/mountd/mountd.c?only_with_tag=MAIN
Here's the referenced PR:
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48282
Essentially, we daemonize after rather than before registering the
serv
Hi there,
at the moment ftp pledges "proc exec" in its SMALL version, but not
otherwise. This seems wrong, because the SMALL version does not support
interactive mode (which needs "proc exec" for e.g. the page command),
while the !SMALL version does.
The patch below switches the two pledges, so t
Hi all,
I'm having trouble with enabling IPv6 routing on my 5.8 gateway.
(Internet)[DHCPv6+PD](em0-GW-axe0)[SLAAC/rtadvd]
My box is connected to Comcast, I'm getting IPv6 address assignment over
DHCPv6 (wide dhcp6c) on WAN interface(em0) together with prefix delegation
and assigning
If we are going to diverge from upstream less, a better starting
point would be https://github.com/gdamore/less-fork
See also http://garrett.damore.org/2014_09_01_archive.html
If you decide to tackle that you'll also want to diff our less
against the stock version to make sure we don't lose any l
On Sun, 01 Nov 2015 09:07:18 -0700, Theo de Raadt wrote:
> > > I think it should be moved into Attic. It's not like we've been nice to
> > > the pcc tree-import either after it lacked attention.
> >
> > I agree, it has been unlinked from the build for more than 5 years.
>
> I don't agree. I sti
Hi,
Implement the list of nd6 llinfo entries with a TAILQ.
ok?
bluhm
Index: netinet6/nd6.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.169
diff -u -p -r1.169 nd6.c
--- netinet6/nd6.c 1
On Oct 26 13:31:14, h...@stare.cz wrote:
> On Oct 24 23:48:01, mark.kette...@xs4all.nl wrote:
> > The diff below makes inteldrm(4) attach directly to pci(4) instead of
> > vga(1). Because inteldrm(4) depends on intagp(4), this also make
> > intagp(4) a child of inteldrm(4). Ultimately I'd like to
On Mon, Oct 26, 2015 at 18:34 +0100, Mike Belopuhov wrote:
> Rather scarce, but that's all we've been given so far.
> I can add more chacha-only test cases, but I don't believe
> that this is strictly necessary.
>
> OK?
>
Update due to Chacha20_Poly1305_* function name changes.
Please note that
On Mon, Oct 26, 2015 at 18:30 +0100, Mike Belopuhov wrote:
> OK?
>
Update due to changes in ChachaPoly-02.
Right now those long lines fit into 80 symbol wide columns,
but I'll see if I can clean it up further and remove those
pesky casts.
OK?
---
sys/conf/files | 2 ++
sys/crypto/cry
On Tue, Oct 27, 2015 at 14:16 +0100, Mike Belopuhov wrote:
> On Mon, Oct 26, 2015 at 18:29 +0100, Mike Belopuhov wrote:
> > OK?
> >
>
> Update due to poly1305.{c,h} changes.
>
3rd update.
I've been asked to use numbers (20 for Chacha and 1305 for Poly)
in function/object names more consistentl
Hi,
To make the nd6 code more like arp, I would like to replace the
llinfo malloc(9) with pool_get(9).
ok?
bluhm
Index: netinet/if_ether.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.17
(without mangling it this time...)
diff --git a/stdlib/malloc.c b/stdlib/malloc.c
index 424dd77..c408594 100644
--- a/stdlib/malloc.c
+++ b/stdlib/malloc.c
@@ -182,6 +182,7 @@ struct malloc_readonly {
int malloc_freeunmap; /* mprotect free pages PROT_NONE? */
int mall
No, I don't think we should do this because it will make updating to
upstream less more difficult, and it is painful enough as it is.
On Sun, Nov 01, 2015 at 02:25:58PM -0500, Michael McConville wrote:
> Every one of these is in a var declaration, so a megadiff is probably
> the easiest way to d
less is code imported on a regular basis from upstream.
Look at the commit log.
> Every one of these is in a var declaration, so a megadiff is probably
> the easiest way to do it.
>
> ok?
>
>
> Index: brac.c
> ===
> RCS file: /cvs/
Every one of these is in a var declaration, so a megadiff is probably
the easiest way to do it.
ok?
Index: brac.c
===
RCS file: /cvs/src/usr.bin/less/brac.c,v
retrieving revision 1.6
diff -u -p -r1.6 brac.c
--- brac.c 25 Apr 20
On Fri, Oct 30, 2015 at 11:51:17PM -0400, Daniel Micay wrote:
> On 26/10/15 04:19 PM, Daniel Micay wrote:
> > This is an improved revision of my earlier patch.
> >
> > It now validates the junk data in the delayed_chunks array in an atexit
> > handler
> > too, rather than just when allocations a
I somehow missed this thread before posting to misc@. I’m using the Nov
1 snapshot with an OpenBSD-only EFI install on the internal SSD of a
2013 MacBook Air and inteldrm(4) does attach but immediately after the
display is corrupted. I can start X just fine but the corruption
remains. I can quit fv
Hi Mark,
Just tried amd64 snapshot (1st Nov) on Intel NUC5i7RYH and building
world from source (updated around 4PM UTC, 1st Nov).
While I do not get any kernel panic or crash as others may have faced,
the behavior of some programs such as firefox, dillo under X (startx
with default install) will g
> 1. I don't see much reason to mention calloc() as an alternative to
> reallocarray() when it's the worse option.
calloc() still remains the portable option. Something should probably
still be mentioned here, otherwise people fall back to unchecked
malloc -- no matter what is stated further belo
Michael McConville wrote:
> Mike Burns wrote:
> > On 2015-11-01 10.44.45 -0500, Michael McConville wrote:
> > > Index: history.c
> > > ===
> > > RCS file: /cvs/src/bin/ksh/history.c,v
> > > retrieving revision 1.52
> > > diff -u -p -r1
1. I don't see much reason to mention calloc() as an alternative to
reallocarray() when it's the worse option.
2. Use size > 0 when testing overflow.
ok?
Index: lib/libc/stdlib/malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc
On 31/10/15(Sat) 08:21, Miod Vallat wrote:
> > While adding MP support to ddb on sparc64 I notice that ddb was
> > inserting breakpoints even if you only entered ddb and used continue
> > again. So I wonder if there is a cache synchronization issue of some
> > sort and by adding those additional i
Mike Burns wrote:
> On 2015-11-01 10.44.45 -0500, Michael McConville wrote:
> > Index: history.c
> > ===
> > RCS file: /cvs/src/bin/ksh/history.c,v
> > retrieving revision 1.52
> > diff -u -p -r1.52 history.c
> > --- history.c 1
On 2015-11-01 10.44.45 -0500, Michael McConville wrote:
> Index: history.c
> ===
> RCS file: /cvs/src/bin/ksh/history.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 history.c
> --- history.c 1 Nov 2015 15:38:53 - 1.52
> +
> > I think it should be moved into Attic. It's not like we've been nice to
> > the pcc tree-import either after it lacked attention.
>
> I agree, it has been unlinked from the build for more than 5 years.
I don't agree. I still have some hope.
Yes, it has problems. But go look at the code in
On Sun, Nov 01, 2015 at 01:10:21PM +0100, Tobias Stoeckmann wrote:
> On Sun, Nov 01, 2015 at 11:17:40AM +, Stuart Henderson wrote:
> > On 2015/11/01 08:03, Nicholas Marriott wrote:
> > > Some did for a while but it has some nasty bugs and nobody is working on
> > > fixing it.
> >
> > Some used
ok?
Index: history.c
===
RCS file: /cvs/src/bin/ksh/history.c,v
retrieving revision 1.52
diff -u -p -r1.52 history.c
--- history.c 1 Nov 2015 15:38:53 - 1.52
+++ history.c 1 Nov 2015 15:44:02 -
@@ -507,7 +507,7 @@ s
Serguey Parkhomovsky wrote:
> Is there any interest in having a newer version of flex in base? I
> recently tried compiling some software with OpenBSD's flex, but had to
> tweak some code in order to get it to compile with 2.5.4. Of course, I
> could always install the flex in ports to get a newer
On Sun, Nov 01, 2015 at 11:17:40AM +, Stuart Henderson wrote:
> On 2015/11/01 08:03, Nicholas Marriott wrote:
> > Some did for a while but it has some nasty bugs and nobody is working on
> > fixing it.
>
> Some used it on amd64 for a while to avoid checkout failures due to
> running into memor
Hi,
relayd (when running relays) will distribute client sessions over hosts
using various algorithms. Some of them generate a hash from different data
and calculate modulo rlt->rlt_nhosts to find the host the session should go
to. If this host is down, the current algorithm simply selects the next
On 2015/11/01 08:03, Nicholas Marriott wrote:
> Some did for a while but it has some nasty bugs and nobody is working on
> fixing it.
Some used it on amd64 for a while to avoid checkout failures due to
running into memory limits, but then I tracked it down and increased
the limit in CVSROOT/option
> This chunk doesn't make sense to me. The code is supposed to write a
> magic value into SRAM, not into a register.
If I understand if_bgereg.h correctly, access to the SRAM can be
performed either through a simple indirect access (write address to the
index register, read from or write to the d
I did partial work before if was called pledge.
Now, with fork and exec, simple pledge is easy.
There might be something down the line to explicitly allow m4 to fork
and exec, but unfortunately, the corresponding macros are used by both
sendmail and autoconf scripts, so I would say they're rathe
Some did for a while but it has some nasty bugs and nobody is working on
fixing it.
On Sun, Nov 01, 2015 at 03:08:54PM +0800, Michael W. Bombardieri wrote:
> I remember reading a while ago that people were thinking to
> use opencvs for anoncvs mirrors. I don't see any mirrors
> reporting as openc
I remember reading a while ago that people were thinking to
use opencvs for anoncvs mirrors. I don't see any mirrors
reporting as opencvs though...
$ for h in $hosts; do printf "%-30s" $h; export CVSROOT="anoncvs@$h:/cvs"; cvs
version | grep -v Client; done ;
anoncvs.au.openbsd.orgServer:
36 matches
Mail list logo
