On Mon, May 13, 2019 at 07:25:37PM -0400, Ted Unangst wrote:
> Jan Klemkow wrote:
> > The diff mainly add sizes to free(9) calls. But, while here fix a
> > malloc(9) call with the wrong size in sr_ioctl_installboot().
> > omi->omi_som is allocated with size of struct sr_meta_crypto, but used
> >
It was mentioned previously that the use of .Sx to refer to a section in
a different manual page is incorrect. I grepped through the src tree to
see if there were any cases of this and I found a couple.
diff --git a/share/man/man4/inet6.4 b/share/man/man4/inet6.4
index f64eedbfb..ddeb27136 100644
Jan Klemkow wrote:
> Hi,
>
> The diff mainly add sizes to free(9) calls. But, while here fix a
> malloc(9) call with the wrong size in sr_ioctl_installboot().
> omi->omi_som is allocated with size of struct sr_meta_crypto, but used
> as struct sr_meta_boot later.
>
> One free(9) with size zero
Hi,
The diff mainly add sizes to free(9) calls. But, while here fix a
malloc(9) call with the wrong size in sr_ioctl_installboot().
omi->omi_som is allocated with size of struct sr_meta_crypto, but used
as struct sr_meta_boot later.
One free(9) with size zero left over in sr_discipline_free().
f. holop wrote:
> dmesg:
>
> ...
> acpibtn2 at acpi0: PWRB
> tpm0 at acpi0: TPM_ addr 0xfed4/0x5000acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD1F
> ...
thanks
On Mon, May 13, 2019 at 02:51:54PM -0700, Andrew Hewus Fresh wrote:
> On Mon, May 13, 2019 at 10:05:16AM -0700, Andrew Hewus Fresh wrote:
> > On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> > > As far as plists go, unless the port only supports py2 or only supports
> > > py3,
This diff changes the way communites are stored and modified in bgpd.
The current implementation was showing that community_*_delete() consumed
a lot of CPU time because of the way rde_attr was used.
Communities are extensivly used by filters (e.g. arouteserver) and
therefor they are stored in an
This changes uvm_unmap_detach() to get rid of the "easy" entries first
before grabbing the kernel lock. Probably doesn't help much with the
lock contention, but it avoids a locking problem that happens with
pools that use kernel_map() to allocate the kva for their pages.
ok?
Index:
dmesg:
...
acpibtn2 at acpi0: PWRB
tpm0 at acpi0: TPM_ addr 0xfed4/0x5000acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
...
--- dev/acpi/tpm.c.orig Mon May 13 23:54:55 2019
+++ dev/acpi/tpm.c Mon May 13 23:55:03 2019
@@ -268,6 +268,7 @@
return;
}
+
On Mon, May 13, 2019 at 10:05:16AM -0700, Andrew Hewus Fresh wrote:
> On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> > As far as plists go, unless the port only supports py2 or only supports py3,
> > it ought to generate the plist with FLAVOR=python3 and then prefix any lines
ok with whitespace fixes below
Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.05.10 15:34:22 +0200:
> This change is from a much larger patch I'm working on. This cleans up
> up_generate_attr() from a hardcoded implementation to a loop-switch
> construct. This way attributes are always dumped in
When using a rule forcing the nexthop to a specific address bgpd
currently does not mark that nexthop as no-modify. In other words
the default rules for nexthop propagation applies. This means that
for ebgp it only sends out the set nexthop when this nexthop is connected
and on the same network as
Jan Klemkow wrote:
> Hi,
>
> The following diff fixes "free with zero size" in sv(4). Builds and
> stats the kernel with sv at pci and audio at sv enabled.
ok
On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> As far as plists go, unless the port only supports py2 or only supports py3,
> it ought to generate the plist with FLAVOR=python3 and then prefix any lines
> ending in ${MODPY_PYCACHE}/ with ${MODPY_COMMENT}.
I think kmos@
On Mon, May 13, 2019 at 09:04:41AM -0700, Andrew Hewus Fresh wrote:
> I was reminded by bluhm@ that I had patches to update perl to the minor
> 5.28.2 release ready shortly before the hackathon. I haven't had time
> to do much testing of it, and unsurprisingly it seems to be mostly full
> of
Index: dev/sgmap_common.c
===
RCS file: /OpenBSD/src/sys/arch/alpha/dev/sgmap_common.c,v
retrieving revision 1.14
diff -u -p -r1.14 sgmap_common.c
--- dev/sgmap_common.c 9 Dec 2014 06:58:28 - 1.14
+++ dev/sgmap_common.c 13
On Mon, May 13, 2019 at 05:53:37PM +0200, Hiltjo Posthuma wrote:
> Tiny typo in a fancy word :)
Fixed, thanks
Tiny typo in a fancy word :)
Patch below:
diff --git usr.bin/ftp/ftp.c usr.bin/ftp/ftp.c
index afb6514efd7..5690f4dbfb9 100644
--- usr.bin/ftp/ftp.c
+++ usr.bin/ftp/ftp.c
@@ -343,7 +343,7 @@ ftp_eprt(FILE *fp)
return -1;
}
- /* Find out the ephermal port chosen
Martijn van Duren wrote:
> >> Would
> >> doas -c /rootdir somecmd
> >> be of any use ?
> >
> > Not particularly opposed, but the extend of this option should be
> > examined. E.g. do we want to extend it to the config to be something
> > similar to -u and limit it's use for certain commands?
> >
Martijn van Duren wrote:
> > But what would it hurt to allow root usage ?
> > Specifically,
> >
> > doas -u ${BUILDUSER} some unquoted command
> >
> > as run by root. This would not open any security hole, would it ?
>
> I don't see any and I've been bitten by having a rootshell open and
>
On 2019/05/13 09:18, Kurt Mosiejczuk wrote:
> On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
>
> > As far as plists go, unless the port only supports py2 or only
> > supports py3, it ought to generate the plist with FLAVOR=python3
> > and then prefix any lines ending in
On Mon, May 13, 2019 at 07:37:36AM +0100, Stuart Henderson wrote:
> As far as plists go, unless the port only supports py2 or only
> supports py3, it ought to generate the plist with FLAVOR=python3
> and then prefix any lines ending in ${MODPY_PYCACHE}/ with
> ${MODPY_COMMENT}.
Yes. I was
inform...@gmx.net (Bruno Flueckiger), 2019.05.12 (Sun) 14:39 (CEST):
> On 01.05., Marcus MERIGHI wrote:
> > Hello,
> >
> > o...@demirmen.com (Okan Demirmen), 2019.04.29 (Mon) 16:19 (CEST):
> > > On Fri 2019.04.26 at 07:15 +0200, Bruno Fl?ckiger wrote:
> > > > Hi,
> > > >
> > > > The ssh menu of
Reyk Floeter writes:
> Hi,
>
> the attached diff fixes filter rules with "forward to" statement in
> persistent (keep-alive) connections. See the XXX comment below.
>
> ```relayd.conf
> log connection
> table {
> 127.0.0.1
> }
> table {
> 127.0.0.1
> }
> table {
>
On 5/13/19 10:00 AM, Martijn van Duren wrote:
> On 5/13/19 9:13 AM, Marc Espie wrote:
>> So, in dpb, I've been forking a lot of 'chroot -u user /build'
>> to build various things, and it works just great.
>>
>> I was wondering about the benefits of
>> su ${BUILDUSER} -c 'some quoted command'
>> vs
On Thu, May 09, 2019 at 02:51:23PM +0200, Reyk Floeter wrote:
> Hi,
>
> this diff adds SNI support to relayd.
>
Below is the same diff again -current minus one debug line.
jsing@ has noted that calling tls_config_set_keypair_ocsp_mem() with
NULL ocsp options could be replaced with
On 5/13/19 9:13 AM, Marc Espie wrote:
> So, in dpb, I've been forking a lot of 'chroot -u user /build'
> to build various things, and it works just great.
>
> I was wondering about the benefits of
> su ${BUILDUSER} -c 'some quoted command'
> vs
> chroot -u ${BUILDUSER} / some unquoted command
>
So, in dpb, I've been forking a lot of 'chroot -u user /build'
to build various things, and it works just great.
I was wondering about the benefits of
su ${BUILDUSER} -c 'some quoted command'
vs
chroot -u ${BUILDUSER} / some unquoted command
Superficially, it looks mostly similar.
The very
As far as plists go, unless the port only supports py2 or only supports
py3, it ought to generate the plist with FLAVOR=python3 and then prefix any
lines ending in ${MODPY_PYCACHE}/ with ${MODPY_COMMENT}.
--
Sent from a phone, apologies for poor formatting.
On 12 May 2019 21:30:34 Andrew
RIT is doing two overnight power outages again starting 5pm (EDT)
Monday May 13th. Accordingly, ftp5.usa.openbsd.org (which is also
ftp3.usa.openbsd.org and ftp.usa.openbsd.org) will be down from Monday
Afternoon until the power comes back on Wednesday morning on May 15th.
--Kurt Mosiejczuk
Does this driver correctly support cua(4) device nodes?
If it doesn't, then my position would be "no, that is a minimum required
featureset". And 'd' dialout support isn't the same, it must be cua.
(Quirky different behaviours between tty devices are super annoying and
end up as complaints on
31 matches
Mail list logo
