As reported on misc@
https://marc.info/?l=openbsd-misc=161016188503894=2
-Otto
Index: regular.c
===
RCS file: /cvs/src/usr.bin/cmp/regular.c,v
retrieving revision 1.12
diff -u -p -r1.12 regular.c
--- regular.c 6 Feb 2015
On Fri, Jan 08, 2021 at 12:59:16PM -0600, Scott Cheloha wrote:
> On Mon, Dec 28, 2020 at 11:41:52AM -0300, Martin Pieuchot wrote:
> > On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> > > Diff below aims to simplify the API to put a thread on a sleep queue and
> > > reduce it to the following:
> >
The global variable "tickadj" has no users in the kernel anymore and
should be eliminated from all code and documentation.
At one time "tickadj" controlled the skew rate for adjtime(2), but it
has been unused since the modern timecounting subsystem was imported
from FreeBSD circa 2004-2005.
On Fri, Jan 08, 2021 at 05:29:31PM -0600, Edgar Pettijohn wrote:
> In the BUGS section for the getopt(3) manual it mentions not using
> single digits for options. I know spamd uses -4 and -6 there are
> probably others. Should they be changed? Or is the manual mistaken?
>
That section seems
By design, nothing sends or generates packets on these interfaces.
OK?
Index: if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.91
diff -u -p -r1.91 if_pflog.c
--- if_pflog.c 28 Aug 2020 12:01:48 -
In the BUGS section for the getopt(3) manual it mentions not using
single digits for options. I know spamd uses -4 and -6 there are
probably others. Should they be changed? Or is the manual mistaken?
Edgar
On Sat, Jan 09, 2021 at 08:22:12AM +1000, Jonathan Matthew wrote:
> The reason I work on vmt(4) is so I don't have to run open-vm-tools, so
> I don't want to see it removed in favour of open-vm-tools.
Totally understandable.
Pleas disregard the diff, then (missing GENERIC hunks).
>
On Fri, Jan 08, 2021 at 10:34:02PM +0100, Klemens Nanni wrote:
> The report on bugs shows vmt(4) lagging behind and I sent a working
> working open-vm-tools port to ports@ yesterday.
>
> In case the port gets imported and there are no further regressions wrt.
> the functionality vmt(4) already
On Sat, Jan 09, 2021 at 07:40:22AM +1000, Jonathan Matthew wrote:
> Anton's fix for parsing of syscall names that are also tokens in the btrace
> grammar broke parsing of 'profile:hz:number', because it forces 'hz' to be
> handled as a string rather than a token. I can't see how we'd ever end up
Anton's fix for parsing of syscall names that are also tokens in the btrace
grammar broke parsing of 'profile:hz:number', because it forces 'hz' to be
handled as a string rather than a token. I can't see how we'd ever end up
with a syscall named 'hz', so one way we could fix this would be to
The report on bugs shows vmt(4) lagging behind and I sent a working
working open-vm-tools port to ports@ yesterday.
In case the port gets imported and there are no further regressions wrt.
the functionality vmt(4) already provides, here's a tentative diff to
remove the driver entirely.
Not
On Fri, Jan 08, 2021 at 10:01:02PM +0100, Pierre Emeriaud wrote:
> anyone wanting to commit this?
Done, thank you.
ping
Le lun. 28 déc. 2020 à 12:21, David Gwynne a écrit :
>
> yes, ok by me.
anyone wanting to commit this?
thanks :)
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.01.07 19:34:23 +0100:
> When bgpd generates an UPDATE to update or withdraw prefixes it does this
> from rde_generate_updates() and then decends into up_generate_update().
> Now there is up_test_update() that checks if a new prefix is actually OK
>
On Fri, Jan 08, 2021 at 11:48:33AM -0600, Scott Cheloha wrote:
> On Fri, Jan 08, 2021 at 05:41:24PM +0100, Mark Kettenis wrote:
> > > Date: Fri, 8 Jan 2021 10:27:38 -0600
> > > From: Scott Cheloha
> > >
> > > On Wed, Jan 06, 2021 at 11:26:27PM +0100, Mark Kettenis wrote:
> > > > > Date: Wed, 6
On Mon, Dec 28, 2020 at 11:41:52AM -0300, Martin Pieuchot wrote:
> On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> > Diff below aims to simplify the API to put a thread on a sleep queue and
> > reduce it to the following:
> >
> > sleep_setup();
> > /* check condition or release lock */
>
On Fri, Jan 08, 2021 at 05:41:24PM +0100, Mark Kettenis wrote:
> > Date: Fri, 8 Jan 2021 10:27:38 -0600
> > From: Scott Cheloha
> >
> > On Wed, Jan 06, 2021 at 11:26:27PM +0100, Mark Kettenis wrote:
> > > > Date: Wed, 6 Jan 2021 16:16:27 -0600
> > > > From: Scott Cheloha
> > > >
> > > > On
This is on top of the "unwind(8): respect DO flag" diff I just sent to
tech.
This is a bit rough around the edges, but if you feel lucky...
Currently unwind(8) only accepts queries over udp. We can get away
with that since we are only listening on localhost and localhost has a
large mtu, but
Rewrite query parsing and answer formating using libunbound provided
functions.
With this we can filter out DNSSEC RRsets if the client did not ask
for them.
We will also be able to send truncated answers to indicate to the
client to switch to tcp (disabled for now since we have no tcp support
> Date: Fri, 8 Jan 2021 10:27:38 -0600
> From: Scott Cheloha
>
> On Wed, Jan 06, 2021 at 11:26:27PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 6 Jan 2021 16:16:27 -0600
> > > From: Scott Cheloha
> > >
> > > On Wed, Jan 06, 2021 at 12:16:13PM -0600, Scott Cheloha wrote:
> > > > As mentioned
On Wed, Jan 06, 2021 at 11:26:27PM +0100, Mark Kettenis wrote:
> > Date: Wed, 6 Jan 2021 16:16:27 -0600
> > From: Scott Cheloha
> >
> > On Wed, Jan 06, 2021 at 12:16:13PM -0600, Scott Cheloha wrote:
> > > As mentioned in a prior mail, tpm(4) is the last user of tvtohz(9) in
> > > the tree.
> > >
On Thu, Jan 07, 2021 at 08:12:10PM -0600, Scott Cheloha wrote:
> On Thu, Jan 07, 2021 at 09:37:58PM +0100, Mark Kettenis wrote:
> > > Date: Thu, 7 Jan 2021 11:15:41 -0600
> > > From: Scott Cheloha
> > >
> > > Hi,
> > >
> > > I want to isolate statclock() from hardclock(9). This will simplify
>
On Thu, Jan 07, 2021 at 11:30:43PM +, Adam Barth wrote:
> Thanks so much! This is my first patch for OpenBSD, and I don't quite have
> the workflow debugged yet.
Committed, thank you!
Probably easiest and safest way is to use git format-patch and to send
the patch file as an attachment.
Hello,
>
> revision 1.294
> date: 2003/01/02 01:56:56; author: dhartmei; state: Exp; lines: +27 -49;
> When route-to/reply-to is used in combination with address translation,
> pf_test() may be called twice for the same packet. In this case, make
> sure the
Right now we don't check for end of sequence or set in most ber places.
This means that valid ber, but invalid ASN1 could be passed down the
codepath.
Since most of the parsing is done with ober_scanf_elements I think it
would be a good idea to add a sequence limiter. rob@ likes the idea and
On Fri, Jan 08, 2021 at 03:43:18PM +0100, Claudio Jeker wrote:
> rpki-client is currently very strict about the ip ranges and as ranges in
> certificates. If a child certificate has a uncovered range in its list it
> is considered invalid and is removed from the pool (with it all the ROA
> entries
On Tue, Jan 05, 2021 at 10:05:39PM +1000, David Gwynne wrote:
> If the idea is to avoid running most of pf_test again if route-to is
> applied during ip_output, I think this tweaked diff is simpler. Is there
> a valid use case for running some of pf_test again after route-to is
> applied?
I found
rpki-client is currently very strict about the ip ranges and as ranges in
certificates. If a child certificate has a uncovered range in its list it
is considered invalid and is removed from the pool (with it all the ROA
entries as well).
Now rfc8360 relaxes this a bit and mentions that a ROA for
28 matches
Mail list logo
