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 all
> > 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 ba
> 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, bu
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 t
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
manu
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 too
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
> 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_ALT
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
> 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 symbol mess.
> > Anyway, the issue is that when
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 X509_check_host/X5
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 "http:
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
>
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 inline and ISO-style inline
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 in
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 send UINT32_MAX
> > and tr
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 http
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 EV
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 swi
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 all
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 protoco
> 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@
>
> Comments? Ok?
ok.
a
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: /cvs/src/sys/dev/rasops/rasops
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 slash.
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?
>
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 I
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.
27 matches
Mail list logo