On Fri, Jan 06, 2017 at 10:31:21PM +0100, Mark Kettenis wrote:
> > Date: Sat, 7 Jan 2017 08:10:02 +1100
> > From: Jonathan Gray
> >
> > On Fri, Jan 06, 2017 at 05:26:36PM +0100, Mark Kettenis wrote:
> > > These are hardware-specific, so it makes sense to only install the
> > > ones relevant for t
Hi tech@,
Here is a diff to use proper RGB values for the ANSI color palette in
rasops(9).
Comments? OK?
Index: sys/dev/rasops/rasops.c
===
RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
retrieving revision 1.44
diff -u -p -r1.44 raso
> Date: Sat, 7 Jan 2017 08:10:02 +1100
> From: Jonathan Gray
>
> On Fri, Jan 06, 2017 at 05:26:36PM +0100, Mark Kettenis wrote:
> > These are hardware-specific, so it makes sense to only install the
> > ones relevant for the (target) hardware.
> >
> > ok?
>
> Looking at the cmake files there is
On Fri, Jan 06, 2017 at 05:26:36PM +0100, Mark Kettenis wrote:
> These are hardware-specific, so it makes sense to only install the
> ones relevant for the (target) hardware.
>
> ok?
Looking at the cmake files there is also a arm_neon.h
generated by llvm's tablegen.
>
>
> Index: gnu/usr.bin/cl
These are hardware-specific, so it makes sense to only install the
ones relevant for the (target) hardware.
ok?
Index: gnu/usr.bin/clang/include/clang/intrin/Makefile
===
RCS file: /cvs/src/gnu/usr.bin/clang/include/clang/intrin/Mak
On 01/06/17 06:28, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
>
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback
On 2017/01/06 15:36, Franco Fichtner wrote:
> Hi Ted,
>
> Thanks, this is very helpful. Don't mind exploring other
> routes as long as they are sustainable within OpenBSD, e.g.
> if kernel changes are needed that they are provided by the
> standard kernel eventually.
>
> > On 3 Jan 2017, at 9:44
Hi Ted,
Thanks, this is very helpful. Don't mind exploring other
routes as long as they are sustainable within OpenBSD, e.g.
if kernel changes are needed that they are provided by the
standard kernel eventually.
> On 3 Jan 2017, at 9:44 PM, Ted Unangst wrote:
>
> Timo Buhrmester wrote:
>>> del
On Fri, 06 Jan 2017 12:27:32 +0100, Mark Kettenis wrote:
> Good point. I don't really see a reason to define _GCC_MAX_ALIGN_T as
> libstdc++ doesn't try to define its own max_align_t like libc++ does.
> We do need to make sure that we define max_align_t for C++11 and up
> though.
Fair enough. OK
Thanks for supporting and rebasing the diff.
On 06.01.17 13:21, Atanas Vladimirov wrote:
On Mon, Dec 05, 2016 at 04:20:02PM +0200, Gregory Edigarov wrote:
Hello,
I know, it considered featuritis, but still, hey, it should go somewhere.
This diff is based on the diff sent here by Stanislav Ada
Hi tech@,
Here's a diff to display color depth alongside resolution when attaching
inteldrm and radeondrm, using the same scheme as efifb(4). This is the
first step in trying to have all frame buffer drivers display resolution
and depth the same way.
Tested only with inteldrm.
On this machine, i
On Fri, Jan 06, 2017 at 12:21:19PM +0100, Martin Pieuchot wrote:
> Right now for pfsync(4), but later it will need it to serialize access
> to PF data structures.
>
> splassert: ip_output: want 1 have 0
> ip_output() at ip_output+0x7d
> pfsync_sendout() at pfsync_sendout+0x499
>
On Fri, Jan 6, 2017 at 12:33 PM, viq wrote:
> I have another issue. I'm preparing OpenBSD vagrant boxes using
> https://packer.io and use it's built in http server to serve install.conf
> file and siteXY.tgz. The whole setup can be seen at
> https://github.com/viq/packer-templates/ and specifical
I have another issue. I'm preparing OpenBSD vagrant boxes using
https://packer.io and use it's built in http server to serve install.conf
file and siteXY.tgz. The whole setup can be seen at
https://github.com/viq/packer-templates/ and specifically
https://github.com/viq/packer-templates/blob/master
On Fri, Jan 06, 2017 at 11:28:34AM +, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
>
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ ->
Related to this (and particularly thinking about autoinstalls),
would it make sense to allow explicit protocols in the hostname?
some.host -> https with http fallback
http://some.host/ -> http only
https://some.host/ -> https only, no fallback
> From: "Todd C. Miller"
> Date: Thu, 05 Jan 2017 15:50:02 -0700
>
> I think you need to also define __CLANG_MAX_ALIGN_T_DEFINED and
> perhaps _GCC_MAX_ALIGN_T to avoid libcxx from redefining max_align_t
> as a different type. E.g. in src/lib/libcxx/include/stddef.h
>
> // Re-use the compiler's
On Mon, Dec 05, 2016 at 04:20:02PM +0200, Gregory Edigarov wrote:
> Hello,
>
> I know, it considered featuritis, but still, hey, it should go somewhere.
> This diff is based on the diff sent here by Stanislav Adaszewski
> (s.adaszev...@gmail.com),
> some time ago.
> I've added one option 'test', i
Right now for pfsync(4), but later it will need it to serialize access
to PF data structures.
splassert: ip_output: want 1 have 0
ip_output() at ip_output+0x7d
pfsync_sendout() at pfsync_sendout+0x499
pfsync_q_ins() at pfsync_q_ins+0x78
pf_remove_state() at
19 matches
Mail list logo
