Hi,
Here a patch that corrects three err() to errx() calls.
- a if condition don't set errno
- strlcpy(3) don't set errno (no mention is man page)
- ca_readpass() already manage errno error message with warn(3)
Comments ? OKs ?
--
Sebastien Marie
Index: ikeca.c
==
New version, based from amd64 5.7 release
The BIOS is supposed to mark any regions used by devices under its control (eg
USB) in the Reserved Memory Range (RMRR).
Some (many?) BIOS get this wrong so we mark the entire e820 reserved area
containing the RMRR region as unusable DMA,
otherwise DMAR
On 11/08/15(Tue) 21:57, Alexander Bluhm wrote:
> On Mon, Aug 10, 2015 at 11:06:52PM +0200, Martin Pieuchot wrote:
> > Convert two rt->rt_refcnt-- to rtfree(rt). In both cases the entry
> > is returned from rtrequest1(RTM_ADD, ...) and wont be freed because
> > it currently *is* in the table.
> >
On Mon, Aug 10, 2015 at 11:06:52PM +0200, Martin Pieuchot wrote:
> Convert two rt->rt_refcnt-- to rtfree(rt). In both cases the entry
> is returned from rtrequest1(RTM_ADD, ...) and wont be freed because
> it currently *is* in the table.
>
> Ok?
You changed from using nrt to rt. Both variables
On Sun, August 9, 2015 11:24 pm, Philip Guenther wrote:
>
> If you're asking for sudo's -i option, sorry, we're out of option
> space in doas. sudo is over there --> ports
>
>
> Philip Guenther
>
That's fair. It's easy enough to work around.
Tim.
On Mon, Aug 10, 2015 at 10:43:46PM +0200, Martin Pieuchot wrote:
> In general these messages do not help. Here we have two cases of
> messages, either logged at LOG_INFO or LOG_ERR.
Yes, multiple logs for the same error are bad. But there is a path
where we ignore the return code of in6_update_i
Hello tech@,
On the 6 Aug snap I ran into this issue:
$ pkg_info | grep libevent
libevent-2.0.22 event notification library
$ pkg-config --atleast-version=2.0.1 libevent && echo yes
Argument "22-stabl" isn't numeric in numeric eq (==) at /usr/bin/pkg-config
line 662.
yes
So it wor
Hi,
I know this will be the third commit to fix the overflow situation in
getusershell if /etc/shells is malformed. Hopefully it will be the last
adjustment.
I submitted a bug report to glibc devs after noticing that they use the
same implementation like we do (more or less). Paul Pluzhnikov revi
Indeed. It would mean we need to be careful. But I think us being careful
here is the least worst alternative.
We also (if we absolutely had to) could bump the minor ahead of base and
catch up or pass it again once possible. But I think for the most part our
changes will mirror base anyway
On Tue
> Yes. I suppose it comes down to can we crank the minor for a portable
> release if it had not been
We could, for about 10 months of the year. For 2 months of the year, this
is difficult. I am not rejecting the idea, but making sure you think about
it.
Yes. I suppose it comes down to can we crank the minor for a portable
release if it had not been
On Tuesday, August 11, 2015, Theo de Raadt wrote:
> But it also means if a new LibreSSL release is going to go out, and there
> hasn't been an ABI crank
>
> > That's actually the point. Because w
But it also means if a new LibreSSL release is going to go out, and there
hasn't been an ABI crank
> That's actually the point. Because while released releases might, if anyone
> is testing snapshot portable builds from github they might not. And still
> don't get fucked.
>
> On Tuesday, Augu
I mean we know we do this right in openbsd. It doesn't make sense to me to
hope the bundlers out there do in a vacuum. Sure they will still fuck up.
But at least this way the horse is properly lead to water
On Tuesday, August 11, 2015, Bob Beck wrote:
> That's actually the point. Because while
That's actually the point. Because while released releases might, if anyone
is testing snapshot portable builds from github they might not. And still
don't get fucked.
On Tuesday, August 11, 2015, Theo de Raadt wrote:
> > I'm wondering out loud if these versions should follow the openbsd shlib
>
> I'm wondering out loud if these versions should follow the openbsd shlib
> major minor numbers. That is where we are careful about semantic
> versioning for api change/add/remove
One note.
If that is decided, on occasion libressl-portable could skip a release
number. Probably fine for everyon
Those values should not be increased. The kernel stack should be treated
like a tight resource.
> I added -Winline to the kernel Makefile and got back the following 2
> warnings:
>
> cc1: warnings being treated as errors
> ../../../../dev/pci/emuxki.c: In function 'emuxki_write_micro':
> ../../.
Hello -
I added -Winline to the kernel Makefile and got back the following 2
warnings:
cc1: warnings being treated as errors
../../../../dev/pci/emuxki.c: In function 'emuxki_write_micro':
../../../../dev/pci/emuxki.c:633: warning: inlining failed in call to
'emuxki_write': --param inline-unit-g
I'm wondering out loud if these versions should follow the openbsd shlib
major minor numbers. That is where we are careful about semantic
versioning for api change/add/remove
On Monday, August 10, 2015, Brent Cook wrote:
> On Mon, Aug 10, 2015 at 5:10 AM, Mark Kettenis > wrote:
> > Jan Engelha
Like ix(4), em(4) hardware doesn't provide an easy/efficient way to
guarantee alignment of protocol headers for received mbufs. The
current code makes an attempt to m_adj() the mbuf if the maximum
hardware frame size is smaller than the cluster size. But ever since
we changed our drivers to alway
On Mon, Aug 10, 2015 at 03:33:47PM -0400, Michael Reed wrote:
> Hi,
>
> I figure that the text which this diff removes wasn't of much use
> besides stating the obvious, as the meaning of list items in the
> ENVIRONMENT section seems pretty consistent across the man pages.
>
> Regards,
> Michael
>
On Tue, Aug 04, 2015 at 10:58:28AM +0200, Clemens Goessnitzer wrote:
> Hello tech@,
>
> I think you spelled one device name wrong. Attached is a patch to correct
> this.
>
> Best regards,
> Clemens
>
fixed, thanks.
jmc
> Index: share/man/man4/axen.4
> ==
21 matches
Mail list logo
