Mention that these functions aren't standard.
OK?
Index: lib/libc/gen/err.3
===
RCS file: /cvs/src/lib/libc/gen/err.3,v
retrieving revision 1.20
diff -u -p -r1.20 err.3
--- lib/libc/gen/err.3 23 Apr 2014 16:26:33 - 1.20
+++
On Wed, Sep 14, 2016 at 12:32 AM, Michal Mazurek wrote:
> Mention that these functions aren't standard.
>
> OK?
Per mdoc(5):
STANDARDS
References any standards implemented or used. If not adhering to
any standards, the HISTORY section should be used instead.
So
Hi again,
On 07.09.2016, at 18:08, tob...@netshed.de wrote:
[..]
>> On 05.09.2016, at 15:50, bust...@gmail.com wrote:
>>
>>> Hey, the typedef came in handy :) Ok bcook@
>>>
>>> On Sep 5, 2016, at 11:52 AM, Bob Beck wrote:
>>>
I am in agreement in principle, but please coordinate with bcoo
Thanks!
On Wed, Sep 14, 2016 at 4:48 AM, wrote:
> Hi again,
>
> On 07.09.2016, at 18:08, tob...@netshed.de wrote:
> [..]
> >> On 05.09.2016, at 15:50, bust...@gmail.com wrote:
> >>
> >>> Hey, the typedef came in handy :) Ok bcook@
> >>>
> >>> On Sep 5, 2016, at 11:52 AM, Bob Beck wrote:
> >>>
Hi
On 14.09.2016, at 13:37, Brent Cook wrote:
>
> Once the expectations of the callbacks are finalized, this needs a good
> explanation in the manual.
Ok, how would I do that best?
I admit to have amended the man page by sheer
copy-and-paste-of-very-small-bits™,
so what would you suggest
On Wed, Sep 14, 2016 at 6:41 AM, Tobias Pape wrote:
> Hi
>
> On 14.09.2016, at 13:37, Brent Cook wrote:
>
> >
> > Once the expectations of the callbacks are finalized, this needs a good
> explanation in the manual.
>
>
> Ok, how would I do that best?
> I admit to have amended the man page by s
This is a work-in-progress diff that I would like to commit. I can print
a few things, but there is a problem when trying to bring in more
fields. Printing is also ugly, but I can fix that in-tree.
While here, I print the descr's as ints, the same way Juniper does it.
I also had to add RTM_INVAL
On Tue, 2016-09-13 at 13:27 +0200, Otto Moerbeek wrote:
> On Thu, Sep 08, 2016 at 06:42:33PM -0400, Daniel Micay wrote:
>
> > A bit off-topic: 'J' enables junk-on-init which is for debugging,
> > but it
> > also currently has security improvements for large allocations.
> > There's
> > only partia
It is quite common to want to do a cross-protocol readvertisement from
IGP->EGP. We can add rtlabels in bgpd and ospfd, but only advertise
in ospfd.
This diff lets bgpd announce routes based on rtlabels. The existing
"cannot announce routes that point to localhost" and "cannot announce
defaults"
Hi Andy,
I just ran into this regression and wrote a similar patch (though I
missed the WEEKLY test).
Thanks for the fix! It solves the Easter-calculation problem I
noticed.
For anyone looking for a quick test, none of the pre- or post-Easter
dates will be displayed when executing:
calendar -t
Hi
On 14.09.2016, at 14:21, Brent Cook wrote:
>
> On 14.09.2016, at 13:37, Brent Cook wrote:
>
> >
> > Once the expectations of the callbacks are finalized, this needs a good
> > explanation in the manual.
>
> [...]
> Generally, what are the expectations of a callback, what should it retur
Dead since the IPV6_PKTOPTIONS socket option was removed.
ok?
Index: ip6_output.c
===
RCS file: /cvs/src/sys/netinet6/ip6_output.c,v
retrieving revision 1.214
diff -u -p -r1.214 ip6_output.c
--- ip6_output.c14 Sep 2016 15:2
On 31 Aug 2016 07:52:19 -0600, "Andy Bradford" wrote:
> While writing a set of regression tests for calendar(1) I discovered a
> bug introduced by my last patch. The following patch fixes that and all
> regression tests in the attachment of tests passes.
I've committed the fix as well as the c
On 14 September 2016 at 17:53, Jeremie Courreges-Anglas wrote:
>
> Dead since the IPV6_PKTOPTIONS socket option was removed.
>
> ok?
>
>
Sure.
Daniel Micay wrote:
>
> The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1,
> and it similarly doesn't wipe at all with 'U' (even though junk-on-free
> also serves the purpose of preventing information leaks, not just
> mitigating use-after-free). IMO, optimizing large allocat
> Daniel Micay wrote:
> >
> > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1,
> > and it similarly doesn't wipe at all with 'U' (even though junk-on-free
> > also serves the purpose of preventing information leaks, not just
> > mitigating use-after-free). IMO, optimizing l
Due to a just-announced power outage happening this Sunday night,
ftp5.usa.openbsd.org will be going down around 7pm EDT (UTC-4) on
Sunday September 14th. I will bring it back up when the power comes
back at midnight EDT, so it should be back up by 1am EDT.
FYI
--Kurt Mosiejczuk
Hi,
nothing defines SAVE_MEMORY nor has it been modified since -r1.1.
ok to zap it?
Index: cread.c
===
RCS file: /cvs/src/sys/lib/libsa/cread.c,v
retrieving revision 1.13
diff -u -p -r1.13 cread.c
--- cread.c 18 Jan 2009 21:46:50
On Wed, 14 Sep 2016 20:41:48 +0200, Jasper Lievisse Adriaanse wrote:
> nothing defines SAVE_MEMORY nor has it been modified since -r1.1.
> ok to zap it?
OK millert@
- todd
Hi,
video(1) fails to read files that were previously recorded with -o
somefile, unless -g (to select read(2) as the input method) is also
specified:
$ video -o foo
^C
$ video -i foo
video: ioctl VIDIOC_REQBUFS: Bad file descriptor
$ video -g -i foo
[ plays the file ]
mmap-mode
So the plan is for rebound to be the 'system' resolver, with libc talking to
rbeound and rebound talking to the cloud. The main wrinkle is how does rebound
find the cloud? rebound.conf, but dhclient doesn't know anything about
rebound.conf, preferring to edit resolv.conf. But if rebound reads
resol
how is rebound going to handle a change in resolv.conf? thats still a
problem here
On Wednesday, 14 September 2016, Ted Unangst wrote:
> So the plan is for rebound to be the 'system' resolver, with libc talking
> to
> rbeound and rebound talking to the cloud. The main wrinkle is how does
> rebou
Bob Beck wrote:
> how is rebound going to handle a change in resolv.conf? thats still a
> problem here
oh, that's easy. it watches the file for changes. i never quite got around to
that, but it's another five lines.
wont this also mean if it is not running i have to wait for the localhost
attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
slow everything down for a timeout?
dont get me wrong, it is an interesting direction, but I think maybe get
the rest of the five line changes into
> wont this also mean if it is not running i have to wait for the localhost
> attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
> slow everything down for a timeout?
i think that is right.
ktrace would show what is going on.
if it stalls, this is not enough.
On Wed, 14 Sep 2016 20:00:32 -0600, Bob Beck wrote:
> wont this also mean if it is not running i have to wait for the localhost
> attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
> slow everything down for a timeout?
Not if he connects to the TCP port 53 instead of the
> > wont this also mean if it is not running i have to wait for the localhost
> > attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
> > slow everything down for a timeout?
>
> Not if he connects to the TCP port 53 instead of the UDP; it looks like
> rebound binds to both.
Bob Beck wrote:
> wont this also mean if it is not running i have to wait for the localhost
> attempt to fail before the resolver moves on? (ASR_STATE_NEXT_NS, etc) so i
> slow everything down for a timeout?
you get back unreachable and move on. it's fast. you can try it. :)
Ted Unangst wrote:
> Bob Beck wrote:
> > how is rebound going to handle a change in resolv.conf? thats still a
> > problem here
>
> oh, that's easy. it watches the file for changes. i never quite got around to
> that, but it's another five lines.
ok, so it's a net +15 lines, including blanks.
In
Thus said "Todd C. Miller" on Wed, 14 Sep 2016 10:04:58 -0600:
> I've committed the fix as well as the calendar regress.
Excellent. I've actually been working on a program that can be put into
regress instead of the large number of files that currently exist for
the expected output; it will g
Yep. and now you need to solve the problem that when prepending 127.0.0.1,
and hitting rebound, which in turn is going to only grab the first dns
server from my resolv.conf instead of all of them, that it now doubles my
failure time when the first dns server doesn't respond (once for libc
asking r
BTW I'm not picking on you.. my DNS setup blew up this week for local
resolution and I've been dealing with the fallout - so the topic
is relatively near and dear to my heart.
On Wed, Sep 14, 2016 at 10:07 PM, Bob Beck wrote:
>
> Yep. and now you need to solve the problem that when prepending
>
It turns out on OMAP4/OMAP5 there is a "Wake-up generator"
interrupt controller that routes interrupts to the GIC and does power
management comparable to imx with the i.MX6 General Power Controller
(GPC).
/ {
#address-cells = <0x0001>;
#size-cells = <0x0001>;
compatible = "ti,o
On Wed, Sep 14, 2016 at 12:53:05PM -0400, Ted Unangst wrote:
> Daniel Micay wrote:
> >
> > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1,
> > and it similarly doesn't wipe at all with 'U' (even though junk-on-free
> > also serves the purpose of preventing information lea
this tree uses all the red-black tree features, so its an interesting
test of the RBT code.
it uses the augment functionality in red black trees, which nothing
else does, and poisons nodes. we dont have any other trees that do
this.
we also get some space back, of course.
ok?
Index: arch/i386/i
35 matches
Mail list logo