Re: clang ld.so regress failures

Mark Kettenis wrote: > FAIL libexec/ld.so/dlclose/test1/prog3/prog3 > > This fails because clang doesn't respect ELF interposition: > > http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html > > We generally frown upon interposition so I can have some sympathy > for their

Re: armv7 void x_intr() vs int x_intr()

On Tue, Aug 01, 2017 at 08:09:01PM -0600, Theo de Raadt wrote: > > (i'm not pointing out the obvious hz*2 'issue' here i think we have on > > armv7;). > > You are missing another detail. > hmmph, and that is? puzzled. -Artturi

Re: armv7 void x_intr() vs int x_intr()

> (i'm not pointing out the obvious hz*2 'issue' here i think we have on > armv7;). You are missing another detail.

pf.c Pflow TOS zeroed out

Hi, We've been maintaining this small patch since 5.8 and it seems to work as expected but could be wrong. Unpatched Behaviour: * netflow always shows TOS values as 0 Patched behaviour: * netflow now shows a TOS value when either set by the PF rule, or if packet originally had the

dhcpd: remove unused structs

I can confirm that the following structs have not been used since at least OpenBSD 4.9. From Edgar Pettijohn. Ok? Index: dhcpd.h === RCS file: /cvs/src/usr.sbin/dhcpd/dhcpd.h,v retrieving revision 1.65 diff -u -p -r1.65 dhcpd.h ---

Re: armv7 void x_intr() vs int x_intr()

> Date: Mon, 31 Jul 2017 16:30:07 +0300 > From: Artturi Alm > > Hi, > > i've been annoyed by this inconsistency for years, and was wondering > if someone would have the time to explain why it is the way it is, or > give me any advice towards the correct fixes. > > i'll

Re: ifstated diff: handling interface depature/arrival

On Mon, Jul 31, 2017 at 05:59:46PM -0400, Rob Pierce wrote: > Good evening all, > > Currently, ifstated does not detect the removal of an IFT_CARP pseudo device. > As such, you can delete a carp interface and have ifstated happily remain in > the current state without detecting any interface

Re: em: workaround for ultra-low-power mode on i219V

On Tue, Aug 01, 2017 at 05:56:54PM +0200, Stefan Fritsch wrote: > Hi, > > we have the problem that on some HP laptops with i219V, it sometimes > happens that em fails to attach with this error: > > em0: Hardware Initialization Failed > em0: Unable to initialize the hardware > > It seems there

em: workaround for ultra-low-power mode on i219V

Hi, we have the problem that on some HP laptops with i219V, it sometimes happens that em fails to attach with this error: em0: Hardware Initialization Failed em0: Unable to initialize the hardware It seems there was some previous discussion of this issue here:

Re: clang ld.so regress failures

On Tue, Aug 01, 2017 at 04:46:17PM +0200, Mark Kettenis wrote: > FAIL libexec/ld.so/dlclose/test1/prog3/prog3 > > This fails because clang doesn't respect ELF interposition: > > http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html > > We generally frown upon interposition

clang ld.so regress failures

Here is my analysis of the ld.so regress failures. None of the actually suggests that there is a bug in ld.so. Cheers, Mark FAIL libexec/ld.so/dlclose/test1/prog3/prog3 This fails because clang doesn't respect ELF interposition:

Re: caesar(6) documents incorrect frequencies

> No ones agree, I think you are mistaken. This is not an exact science, it is an approximation. However one of there is well-known, and the others are calculation-de-jour.

Re: caesar(6) documents incorrect frequencies

On Tue, Aug 1, 2017 at 9:49 AM, Theo de Raadt wrote: >> > Is it possible you've got the fix backwards? I think ETAONRISHetc is >> > from some well-known research, but ETSAOR* is brand new and even google >> > cannot find a reference to that ordering. It seems there is a bug

Re: caesar(6) documents incorrect frequencies

> > Is it possible you've got the fix backwards? I think ETAONRISHetc is > > from some well-known research, but ETSAOR* is brand new and even google > > cannot find a reference to that ordering. It seems there is a bug here, > > but is it perhaps the other frequency table? > > I certainly don't

Re: caesar(6) documents incorrect frequencies

On Tue, Aug 01, 2017 at 07:38:28AM -0600, Theo de Raadt wrote: > > On Tue, Aug 01, 2017 at 07:28:39AM -0600, Theo de Raadt wrote: > > > I've known about ETAONRISHetc basically forever. Where is this new > > > order (ETSAORINDHLCPMUYFWGBVKXQZJ) coming from. > > > > > > Citation please? > > > >

Re: caesar(6) documents incorrect frequencies

> On Tue, Aug 01, 2017 at 07:28:39AM -0600, Theo de Raadt wrote: > > I've known about ETAONRISHetc basically forever. Where is this new > > order (ETSAORINDHLCPMUYFWGBVKXQZJ) coming from. > > > > Citation please? > > I'm just updating the man page to reflect the percentages in caesar.c > which

Re: caesar(6) documents incorrect frequencies

On Tue, Aug 01, 2017 at 07:28:39AM -0600, Theo de Raadt wrote: > I've known about ETAONRISHetc basically forever. Where is this new > order (ETSAORINDHLCPMUYFWGBVKXQZJ) coming from. > > Citation please? I'm just updating the man page to reflect the percentages in caesar.c which claims to get

Re: caesar(6) documents incorrect frequencies

I've known about ETAONRISHetc basically forever. Where is this new order (ETSAORINDHLCPMUYFWGBVKXQZJ) coming from. Citation please? > On Tue, Aug 01, 2017 at 09:36:13AM +0100, Jason McIntyre wrote: > > On Thu, Jul 27, 2017 at 01:36:15AM -0500, Matthew Martin wrote: > > > The man page documents

Re: caesar(6) documents incorrect frequencies

On Tue, Aug 01, 2017 at 09:36:13AM +0100, Jason McIntyre wrote: > On Thu, Jul 27, 2017 at 01:36:15AM -0500, Matthew Martin wrote: > > The man page documents frequencies that are different than the code > > uses e.g. C (3.61 vs 2.7) and D (4.78 vs 3.8). This seems a bit much for > > a man page. If

Re: Changing default compiler for usr/ports buiding

Ok, but how to point cmake-3.5.2 to build the needed "source" which using Boost 1.53 or higher libraries ver.? Boost 1.59.0 itself was downloaded from boost web site and builded from sources using gcc 4.9 already. Some patches have been installed. I have tried to point cmake-3.5.2 to

Re: [diff] typo in tls_load_file.3

On Sat, Jul 29, 2017 at 03:15:56PM -0700, Carlos Cardenas wrote: > Missing 'ocsp' in the function name. > fixed, thanks. jmc > +--+ > Carlos > > diff --git lib/libtls/man/tls_load_file.3 lib/libtls/man/tls_load_file.3 > index fcaa5eef029..b83f55e0fe4 100644 > --- lib/libtls/man/tls_load_file.3

Re: caesar(6) documents incorrect frequencies

On Thu, Jul 27, 2017 at 01:36:15AM -0500, Matthew Martin wrote: > The man page documents frequencies that are different than the code > uses e.g. C (3.61 vs 2.7) and D (4.78 vs 3.8). This seems a bit much for > a man page. If anyone prefers the letter ordering be kept, the correct > order is

ftp(1): remove self assignment

Hi, Discovered while compiling with `-Wall`. My guess is that this line was added back in 2004 in order to silence a compiler warning since the parameter is not used. Unfortunately it can't be removed since the function prototype is dictated by el_set(3). Comments? OK? Index: complete.c