Gleydson Soares(gsoa...@gmail.com) on 2017.03.27 16:43:28 -0300:
> > What about the other calls to calloc(3); shouldn't we keep their
> > respective error messages consistent?
>
> seems that several err()/errx() calls in pfctl code are hard-coding
> the function name...
>
> instead of hard code,
nice!
Job Snijders(j...@instituut.net) on 2017.03.28 14:12:42 -0500:
> Dear all,
>
> BGP Origin Validation State communities are non-transitive opaque
> extended communities to carry the origination Autonomous System
> validation state inside an autonomous system. IBGP speakers that
> receive
Dear all,
BGP Origin Validation State communities are non-transitive opaque
extended communities to carry the origination Autonomous System
validation state inside an autonomous system. IBGP speakers that
receive this validation state can configure local policies that allow it
to influence their
On Tue, 28 Mar 2017 09:33:53 -0600, "Todd C. Miller" wrote:
> It seems to me that in -C mode it should really process all the
> checksums that match the specified file(s), but the documentation
> does not actually specify what the behavior is in this case.
Here's a diff that accomplishes that.
On Tue, 28 Mar 2017 15:49:24 +0100, Craig Skinner wrote:
> When cksum(1) is used with a -C checklist listing multiple algorithms,
> and a single -a algorithm is specified, cksum doesn't select the correct
> -a [algorithm], nor the correct line in the -C [checklist]:
The -a option is only used to
I'm still unable to use the I219_v2 onboard nic. I've posted my dmesg bellow.
Dhclient does not recieve an ip address.
Tiemen Werkman
OpenBSD 6.1-beta (GENERIC.MP) #1: Sat Mar 25 08:33:54 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8456712192
Hiya,
When cksum(1) is used with a -C checklist listing multiple algorithms,
and a single -a algorithm is specified, cksum doesn't select the correct
-a [algorithm], nor the correct line in the -C [checklist]:
$ uname -mrsv # standard 6.0 release
OpenBSD 6.0 GENERIC#1917 i386
$ date
Hello Mike,
thank you for looking at my patch. I accept most of your comments.
I believe the items below deserve further discussion.
> - instead of checking "rv" against 0 in the "break on quick
>rule or failure" I'd like to see an actual check against
>PF_TEST_* values so that it's
