Re: Explicitly check PF_TRANS_RULESET

On Thu, Jan 18, 2018 at 11:12:59PM -0500, Lawrence Teo wrote: > The pf(4) DIOCX{BEGIN,COMMIT,ROLLBACK} calls support two ruleset types: > PF_TRANS_RULESET and PF_TRANS_TABLE. > > However, their switch statements in pf_ioctl.c only check for > PF_TRANS_TABLE and do not check PF_TRANS_RULESET at

Re: Zap PF_TRANS_ALTQ

> > On Fri, Jan 19, 2018 at 08:24:23PM +, Stuart Henderson wrote: > > > To be honest though, unless it's in the way of something, I'm not sure > > > it's > > > worth removing. > > > > If those constatns are in ports and require revision bumps, we can > > leave it in the header. Rebuilding

Re: Zap PF_TRANS_ALTQ

> On Fri, Jan 19, 2018 at 08:24:23PM +, Stuart Henderson wrote: > > To be honest though, unless it's in the way of something, I'm not sure it's > > worth removing. > > If those constatns are in ports and require revision bumps, we can > leave it in the header. Rebuilding base is one thing,

Re: Zap PF_TRANS_ALTQ

On 2018/01/19 21:46, Alexander Bluhm wrote: > On Fri, Jan 19, 2018 at 08:24:23PM +, Stuart Henderson wrote: > > To be honest though, unless it's in the way of something, I'm not sure it's > > worth removing. > > If those constatns are in ports and require revision bumps, we can > leave it in

Re: Zap PF_TRANS_ALTQ

On Fri, Jan 19, 2018 at 08:24:23PM +, Stuart Henderson wrote: > To be honest though, unless it's in the way of something, I'm not sure it's > worth removing. If those constatns are in ports and require revision bumps, we can leave it in the header. Rebuilding base is one thing, but doing

Re: Zap PF_TRANS_ALTQ

On 2018/01/19 15:07, Alexandr Nedvedicky wrote: > On Thu, Jan 18, 2018 at 11:15:41PM -0500, Lawrence Teo wrote: > > Nothing uses PF_TRANS_ALTQ anymore, so zap it. > > > > ok? > > I'm fine with removing it. I'm just concerned about potential impact > on port tree as there might be some

Building clang on sparc64

I just committed the bits to start building clang on sparc64. While it is possible to bootstrap clang yourself using the same procedure as we used for other architectures, I really recommend upgrading to a snapshot. Snapshots with clang should become available in a couple of days. Cheers, Mark

Re: Zap PF_TRANS_ALTQ

> On Thu, Jan 18, 2018 at 11:15:41PM -0500, Lawrence Teo wrote: > > Nothing uses PF_TRANS_ALTQ anymore, so zap it. > > > > ok? > > I'm fine with removing it. I'm just concerned about potential impact > on port tree as there might be some tool/library still trying to use >

Re: Zap PF_TRANS_ALTQ

On Thu, Jan 18, 2018 at 11:15:41PM -0500, Lawrence Teo wrote: > Nothing uses PF_TRANS_ALTQ anymore, so zap it. > > ok? I'm fine with removing it. I'm just concerned about potential impact on port tree as there might be some tool/library still trying to use PF_TRANS_ALTQ. I just don't

Re: libc softfloat diff

> From: Jeremie Courreges-Anglas > Date: Fri, 19 Jan 2018 15:28:20 +0100 > > On Fri, Jan 19 2018, Mark Kettenis wrote: > > I thought I had built a snap with armv7, but apparently I didn't. Or > > at least I didn't since I made changes to the whole

Patch to libcrypto's X509_check_(host|email) functions to behave like documented

Hi, I originally created this on github[0], but as it's not part of the portable bits, I've asked to post this on this OpenBSD tech mailing list, I hope this is the correct way of addressing this. The attached patch aims to fix an API difference between OpenSSL and LibreSSL for

Re: httpd: mess with PATH_INFO (again)

On Thu, Jan 18, 2018 at 10:18:29AM +, Stuart Henderson wrote: > I think it should skip redirecting for "". You can't actually issue an > HTTP request for http://example.com (without the trailing slash). > > 'A PATH_INFO of "/" represents a single void path segment.' > > I think that is

Re: Zap PF_TRANS_ALTQ

On Thu, Jan 18, 2018 at 11:15:41PM -0500, Lawrence Teo wrote: > Nothing uses PF_TRANS_ALTQ anymore, so zap it. > > ok? This means that people have to recompile their pfctl and some other tools together with the kernel. But that should not prevent code cleanup. OK bluhm@ > Index: pfvar.h >

Re: libc softfloat diff

On Fri, Jan 19 2018, Mark Kettenis wrote: > I thought I had built a snap with armv7, but apparently I didn't. Or > at least I didn't since I made changes to the whole symbol mess. > Anyway, the issue is that when building ramdisk code the difference > between GCC-style

Re: relayd and PUT

Hi! On Fri, 2018-01-05 at 00:12 +0100, Alexander Bluhm wrote: > I have commited more regression tests that check the timeout with > unidirectional traffic flow. I could not find an error. In theory > when we have an idle timeout in one direction, relayd checks wheter > there is trafic flowing

Re: VMD: vioscsi - fix large iso support

On Fri, Jan 19, 2018 at 07:35:08PM +1000, David Gwynne wrote: > > > > On 19 Jan 2018, at 4:32 pm, Carlos Cardenas wrote: > > > > Howdy. > > > > Attached is a patch to fix handling images > 4GB support in Linux. I > > confused image size vs blocks to determine when to

Re: relayd and PUT

Hi! Please ingore this. Rivo On Fri, 2018-01-19 at 14:01 +, Rivo Nurges wrote: > On Fri, 2018-01-05 at 00:12 +0100, Alexander Bluhm wrote: > > On Wed, Dec 13, 2017 at 07:42:03AM +0100, Claudio Jeker wrote: > > > On Wed, Dec 13, 2017 at 12:25:39AM +, Rivo Nurges wrote: > > > > If you

Re: relayd and PUT

On Fri, 2018-01-05 at 00:12 +0100, Alexander Bluhm wrote: > On Wed, Dec 13, 2017 at 07:42:03AM +0100, Claudio Jeker wrote: > > On Wed, Dec 13, 2017 at 12:25:39AM +, Rivo Nurges wrote: > > > If you http PUT a "big" file through relayd, server<>relay read > > > side > > > will eventually get a

libc softfloat diff

I thought I had built a snap with armv7, but apparently I didn't. Or at least I didn't since I made changes to the whole symbol mess. Anyway, the issue is that when building ramdisk code the difference between GCC-style inline and ISO-style inline rears its ugly head again. The solution is to

Re: Explicitly check PF_TRANS_RULESET

On Thu, Jan 18, 2018 at 11:12:59PM -0500, Lawrence Teo wrote: > The pf(4) DIOCX{BEGIN,COMMIT,ROLLBACK} calls support two ruleset types: > PF_TRANS_RULESET and PF_TRANS_TABLE. > > However, their switch statements in pf_ioctl.c only check for > PF_TRANS_TABLE and do not check PF_TRANS_RULESET at

Re: Basic SHA3 support (cryptographic discussion)

On Wed, Jan 17, 2018 at 10:20:50PM +0100, Christian Weisgerber wrote: > What do you want to USE your SHA-3 implementation for? I would like to have a sha3 command line tool. Just to have it there and start using it. For example adding it to ports distfiles would be trivial. Yes, general

Re: VMD: vioscsi - fix large iso support

> On 19 Jan 2018, at 4:32 pm, Carlos Cardenas wrote: > > Howdy. > > Attached is a patch to fix handling images > 4GB support in Linux. I > confused image size vs blocks to determine when to send UINT32_MAX > and trigger a READ_CAPACITY_16. > > Identified by mlarkin@ >

rasops(9): Fix underline rotation on CCW rotated screens

Hi tech@, Fix underline rotation on CCW (quarter counter-clockwise) rotated screens. Currently, the "underline" is actually drawn above text. Comments? OK? Index: sys/dev/rasops/rasops.c === RCS file:

Re: httpd: mess with PATH_INFO (again)

The WSGI PEP states the following: > PATH_INFO > The remainder of the request URL's "path", designating the virtual > "location" of the request's target within the application. This may be > an empty string, if the request URL targets the application root and > does not have a trailing

Re: VMD: vioscsi - fix large iso support

On Thu, Jan 18, 2018 at 10:32:31PM -0800, Carlos Cardenas wrote: > Howdy. > > Attached is a patch to fix handling images > 4GB support in Linux. I > confused image size vs blocks to determine when to send UINT32_MAX > and trigger a READ_CAPACITY_16. > > Identified by mlarkin@ > > Comments? Ok?

Re: httpd: mess with PATH_INFO (again)

On Fri, Jan 19, 2018 at 08:29:13AM +0100, Ve Telko wrote: > Hi, > > problem is in your framework, server handles this correctly. > > Using PHP, PATH_INFO and > REQUEST_URI is always "/" > > for URLs like > http://foo.bar > http://foo.bar/ > http://foo.bar// > > Ve. > It's not over here, and

Re: httpd: mess with PATH_INFO (again)

Hi, problem is in your framework, server handles this correctly. Using PHP, PATH_INFO and REQUEST_URI is always "/" for URLs like http://foo.bar http://foo.bar/ http://foo.bar// Ve.