On 2016/06/23 00:25, Ted Unangst wrote:
> Stuart Henderson wrote:
> > Turns out I forgot about the pthread stubs, without which there
> > are build failures in mandoc and various ports things unless we link
> > them with -lpthread. This broke a few things in my first ports test
> > build, but thank
On Wed, Jun 22, 2016 at 10:54:27PM +1000, David Gwynne wrote:
> secondly, allocating more than 4g at a time to socket buffers is
> generally a waste of memory. in practice you should scale the amount
> of memory available to sockets according to the size of the tcp
> windows you need to saturate th
You guys made me think about the actual use case: noob user of OpenBSD,
installs the ISO, never gets to have any pkg.conf by default.
A way to handle that case would be to have non-network iso *installs* put
a pkg.conf that says "hey we didn't configure anything, let's do that later".
A bit a la
> Date: Thu, 23 Jun 2016 13:09:28 +0200
> From: Alexander Bluhm
>
> On Wed, Jun 22, 2016 at 10:54:27PM +1000, David Gwynne wrote:
> > secondly, allocating more than 4g at a time to socket buffers is
> > generally a waste of memory. in practice you should scale the amount
> > of memory available t
On Thu, Jun 23, 2016 at 09:03:43AM +0100, Stuart Henderson wrote:
> On 2016/06/23 00:25, Ted Unangst wrote:
> > Stuart Henderson wrote:
> > > Turns out I forgot about the pthread stubs, without which there
> > > are build failures in mandoc and various ports things unless we link
> > > them with -l
On Thu, Jun 23, 2016 at 00:38 +0200, Alexander Bluhm wrote:
> On Wed, Jun 22, 2016 at 08:15:09PM +0200, Mike Belopuhov wrote:
> > Can you or benno test NAT64 with this change?
> > In case of weird behavior do this:
> >
> > int sidx = pd->af == pd->naf ? pd->sidx : pd->didx;
> > int didx = pd->af =
Hi,
Following http://marc.info/?l=openbsd-tech&m=142136923124184&w=2 which
added TLS client support in syslogd and since now libtls supports client
certificates, this patch adds client's certificate support in syslogd
for mutual authentication to a remote syslog server.
It is based on code f
Mark Kettenis [mark.kette...@xs4all.nl] wrote:
>
> We really don't want to implement bounce-buffers. Adding IOMMU
> support is probably a better approach as it also brings some security
> benefits. Not all amd64 hardware supports an IOMMU. And hardware
> that does support it doesn't always have
On 2016/06/15 19:43, Vincent Gross wrote:
> On Mon, 13 Jun 2016 16:49:01 +0200
> Vincent Gross wrote:
> >
> > While validating source address inside selection functions is the
> > right direction, I don't think it would be a good thing to extend
> > further in_selectsrc() prototype. However it is
Hi,
This is a revised diff from the previous one I sent regarding updating
the log command to be a bit more similar to GNU cvs.
This diff now also fixes a bunch of segfaults with rare corner cases.
There are still several problems with log however, including not properly
iterating over Attic fil
Hi,
Diff fixes a two broken regression tests for opencvs.
.joris
Index: Makefile
===
RCS file: /cvs/src/regress/usr.bin/cvs/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile13 Jul 2010 21:31:17 -
Instead of using the old flags and tsleep style lock, switch to rwlock in
sblock. That's what it's for. More legible, and as a bonus, MP safer.
Index: kern/uipc_socket2.c
===
RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
retrieving re
On 23/06/16 18:14, Kapetanakis Giannis wrote:
Hi,
Following http://marc.info/?l=openbsd-tech&m=142136923124184&w=2 which
added TLS client support in syslogd and since now libtls supports
client certificates, this patch adds client's certificate support in
syslogd for mutual authentication to
# route delete 1.1.1.1
route: writing to routing socket: No such process
delete host 1.1.1.1: not in table
The first error is unnecessary and misleading. It comes from the rtmsg()
function, but another error will be printed by the caller, which will also
perform correct errno translation.
On Thu, 23 Jun 2016 13:13:57 -0400, "Ted Unangst" wrote:
> # route delete 1.1.1.1
> route: writing to routing socket: No such process
> delete host 1.1.1.1: not in table
>
> The first error is unnecessary and misleading. It comes from the rtmsg()
> function, but another error will be prin
Todd C. Miller wrote:
> On Thu, 23 Jun 2016 13:13:57 -0400, "Ted Unangst" wrote:
>
> > # route delete 1.1.1.1
> > route: writing to routing socket: No such process
> > delete host 1.1.1.1: not in table
> >
> > The first error is unnecessary and misleading. It comes from the rtmsg()
> > fu
On Thu, 23 Jun 2016 13:46:55 -0400, "Ted Unangst" wrote:
> yes, i think the caller should do the most checking.
>
> (there is still a warning in rtmsg() for reading, but it will return 0 even
> for failure in that case, so no double warning.)
OK millert@ for the revised diff.
- todd
just because.
Index: logname.c
===
RCS file: /cvs/src/usr.bin/logname/logname.c,v
retrieving revision 1.9
diff -u -p -r1.9 logname.c
--- logname.c 9 Oct 2015 01:37:08 - 1.9
+++ logname.c 24 Jun 2016 01:02:58 -
@@ -32
A few changes to improve readability. Remove lots of casts. Casting printf is
just noise. Casting signal() is also uncommon in our tree. I kept a casts for
functions like write() where we would normally expect to check the error. (For
that matter, why do we ignore failure to write failedlogin?)
Al
These programs don't do anything interesting based on progname, except to echo
is back to the user. If the user creates a link, is it somehow more correct
to print that name? I'd argue the original name is better (especially in
usage) because then you have a hint what man page to read.
Index: rad
With these changes applied, and by specifying MAKESRCDIRPREFIX/MAKEOBJDIRPREFIX,
I can build tree without creating obj symlinks under source.
If src directory is /a/src, and obj is /b/obj, use
MAKESRCDIRPREFIX=/a/src
MAKEOBJDIRPREFIX=/b/obj
then .OBJDIR under /a/src/bin/ls becomes
Why?
I've been here for a while. My experiences:
Lots of variations of build environment -> lots of failure
conditions happen -> many people wasting their time.
Please supply a good justification why that is good.
If you can't, throw your diff away. It Simple as that.
> With these changes ap
Theo de Raadt wrote:
> Why?
>
> I've been here for a while. My experiences:
>
> Lots of variations of build environment -> lots of failure
> conditions happen -> many people wasting their time.
>
> Please supply a good justification why that is good.
Actually, it's kind of interesting. Taking
Hi,
If people are interested in opencvs diffs again, sharing a rcsnum_free()->free()
clean-up item. Note that rcs(1) also has a version of rcsnum_free() which does
more
than simply call free().
- Michael
Index: add.c
===
RCS file:
24 matches
Mail list logo