On 2014/12/08 15:04, David Higgs wrote:
> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
> parsing of SENSOR_INDICATOR values. Since parsing as integers was both
> undocumented and confusing, it is no longer supported. Also, bail on
> error if the high/low values don’t create a vali
Hi,
I'm linking haproxy (current git master) against libressl 2.1.2
portable on linux, but seeing 2 issues (not present in previous
libressl 2.1.1):
Issue number one (not sure what happens here):
include/openssl/ssl.h:503:2: error: unknown type name ‘uint8_t’
uint8_t *tlsext_ecpointformatlist
On 2014/12/09 12:30, Lukas Tribus wrote:
> Hi,
>
> I'm linking haproxy (current git master) against libressl 2.1.2
> portable on linux, but seeing 2 issues (not present in previous
> libressl 2.1.1):
>
>
> Issue number one (not sure what happens here):
>
> include/openssl/ssl.h:503:2: error: un
On Tue, Dec 9, 2014 at 6:18 AM, Stuart Henderson wrote:
> On 2014/12/09 12:30, Lukas Tribus wrote:
>> Hi,
>>
>> I'm linking haproxy (current git master) against libressl 2.1.2
>> portable on linux, but seeing 2 issues (not present in previous
>> libressl 2.1.1):
>>
>>
>> Issue number one (not sure
Hi all,
I made a small first diff to replace some ato* functions call to strtonum/l
ones ...
Althought not sure about the sudo one because it looks contrib code and
also might appear a bit "overengineered" ... but in case !
Thanks in advance.
Index: bin/ps/ps.c
==
Working and non-working dmesgs from the same VM below. Let me know if
any more info is needed. If this is already known, sorry for the
noise.
--david
# does not work
OpenBSD 5.6-current (RAMDISK_CD) #555: Tue Dec 9 00:50:21 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/
On 2014/12/09 08:37, David Higgs wrote:
> Working and non-working dmesgs from the same VM below. Let me know if
> any more info is needed. If this is already known, sorry for the
> noise.
gonzalo@ has seen similar on vr(4) starting recently, but the timing
doesn't quite match yours.
> # does no
> Date: Tue, 9 Dec 2014 14:12:20 +
> From: Stuart Henderson
>
> On 2014/12/09 08:37, David Higgs wrote:
> > Working and non-working dmesgs from the same VM below. Let me know if
> > any more info is needed. If this is already known, sorry for the
> > noise.
>
> gonzalo@ has seen similar on
On 2014/12/09 07:37, Brent Cook wrote:
> If an app calls a function, it should probably check if that function
> exists during configuration time, rather than inferring if define A
> exists, function B and C must exist. Especially things that are just
> protocol constant definitions. If they are us
On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson wrote:
> On 2014/12/08 15:04, David Higgs wrote:
>> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
>> parsing of SENSOR_INDICATOR values. Since parsing as integers was both
>> undocumented and confusing, it is no longer supported. Al
On 2014/12/09 09:36, David Higgs wrote:
> On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson wrote:
> > On 2014/12/08 15:04, David Higgs wrote:
> >> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
> >> parsing of SENSOR_INDICATOR values. Since parsing as integers was both
> >> undocum
I was playing with afl a few weeks ago and found this. I believe it is
triggered by non-sequential timestamp records, but I didn’t dig into it or run
afl for particularly long. The patch below fixed all the crashes afl had found
up to that point.
The string used doesn’t matter, ‘crmsg’ just n
On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson wrote:
> On 2014/12/09 09:36, David Higgs wrote:
>> On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson wrote:
>> > On 2014/12/08 15:04, David Higgs wrote:
>> >> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
>> >> parsing of SENSOR_IN
On Tue, Dec 9, 2014 at 9:19 AM, Mark Kettenis wrote:
>> Date: Tue, 9 Dec 2014 14:12:20 +
>> From: Stuart Henderson
>>
>> On 2014/12/09 08:37, David Higgs wrote:
>> > Working and non-working dmesgs from the same VM below. Let me know if
>> > any more info is needed. If this is already known,
> On 2014/12/09 07:37, Brent Cook wrote:
>> If an app calls a function, it should probably check if that function
>> exists during configuration time, rather than inferring if define A
>> exists, function B and C must exist. Especially things that are just
>> protocol constant definitions. If they
On Tue, Dec 09, 2014 at 13:38, David Carlier wrote:
> -pid = atol(optarg);
> +pid = (pid_t)strtonum(optarg, -1, (SHRT_MAX - 1), &errstr);
> +if (errstr)
> +errx(1, "pid: %s", errstr);
This should definitely use PID_MAX I think. (If that's not ex
yes, my scenario is:
Alix (i386) with vr0 and vr1.
vr0 connected to my ISP modem as always with:
cat /etc/hostname.vr0
dhcp
So far so go on boot time with #507 snapshot (No
On Dec 8, 2014, at 6:07 PM, Martin Pieuchot wrote:
> On 08/12/14(Mon) 09:35, David Higgs wrote:
>> On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot
>> wrote:
>> [...]
>>> Now I'd like to finish the transition that started with the import of
>>> upd(4) and move away from the actual 1 reportID = 1
Slighty different version, so withdrawal of casts and strtol => strtonum.
I still maintain (SHRT_MAX - 1) as PID_MAX is not exposed to the userland
(@tedu mentioned he planned to increase it,
would it be good to expose it via, for example, sysctl which makes it also
settable ?)
Index: bin/ps/ps.
Dear Tech,
i have a ENDAT 7703 motherboard near my desk,
the manual point out some instruction to configure the
watchdog :
//init, select the destination of command...
outportb(0x2e,0x87);
outportb(0x2e,0x87);
outportb(0x2e,0x07);
outportb(0x2f,0x08);
//com
outportb(0x2e,0x30); //main
outport
On 2014-12-03, Mike Belopuhov wrote:
> bpf aligns data following the datalink header (e.g. ethernet)
> on the BPF_ALIGNMENT boundary. Since rev1.41 of bpf.h it's
> uint32_t instead of a long. And also since then almost all
> packets become "unaligned" from the tcpdump perspective and
> require
* Ted Unangst [2014-12-08 13:28:36]:
> On Mon, Dec 08, 2014 at 11:52, Matt Dainty wrote:
> > * Jonathan Gray [2014-12-08 08:08:19]:
> >>
> >> Well any name that includes gpio that isn't taken should be fine.
> >
> > I went with soekrisgpio(4) as there are longer driver names in the tree,
> > (ac
On 9 December 2014 at 19:00, Christian Weisgerber wrote:
> On 2014-12-03, Mike Belopuhov wrote:
>
>> bpf aligns data following the datalink header (e.g. ethernet)
>> on the BPF_ALIGNMENT boundary. Since rev1.41 of bpf.h it's
>> uint32_t instead of a long. And also since then almost all
>> packe
>
> Dear Tech,
>
> i have a ENDAT 7703 motherboard near my desk,
> the manual point out some instruction to configure the
> watchdog :
>
> //init, select the destination of command...
>
> outportb(0x2e,0x87);
> outportb(0x2e,0x87);
> outportb(0x2e,0x07);
> outportb(0x2f,0x08);
>
> //com
>
> o
Hello tech@.
I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64 kernel
config doesn't do neither isapnp, nor eisa.
Looks like a remnant after i386 intro(4).
Cheers,
Alexey
This diff replaces hash32 by SipHash in the hash table in ospf{,6}d/lsupdate.c.
Seems pretty straightforward...
Index: usr.sbin/ospfd/lsupdate.c
===
RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v
retrieving revision 1.41
diff -u -p -
On Tue, Dec 09, 2014 at 10:27:45PM +0200, Alexey Suslikov wrote:
> Hello tech@.
>
> I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64 kernel
> config doesn't do neither isapnp, nor eisa.
>
> Looks like a remnant after i386 intro(4).
>
> Cheers,
> Alexey
>
those pages are not M
Jason McIntyre kerhand.co.uk> writes:
> On Tue, Dec 09, 2014 at 10:27:45PM +0200, Alexey Suslikov wrote:
> > I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64
kernel
> > config doesn't do neither isapnp, nor eisa.
>
> those pages are not MD, so they display for all archs. that'
On Mon, Dec 08, 2014 at 12:04:58PM +0100, Martin Pieuchot wrote:
> Is it ok?
OK bluhm@
>
> Index: net/pf.c
> ===
> RCS file: /home/ncvs/src/sys/net/pf.c,v
> retrieving revision 1.896
> diff -u -p -r1.896 pf.c
> --- net/pf.c 20 Nov
Hi,
in summer, I posted some paravirt patches for amd64. In response to the
comments I received then, I have created some infrastructure to binary
patch kernel code during boot. In order to get some feedback, I am posting
the whole paravirt & code patching diff here. Also, KVM users may be
int
On Mon, Dec 08, 2014 at 12:13:11PM +0100, Martin Pieuchot wrote:
> On 04/12/14(Thu) 00:26, Alexander Bluhm wrote:
> > On Wed, Nov 26, 2014 at 12:58:35PM +0100, Martin Pieuchot wrote:
> > > @@ -761,7 +754,17 @@ report:
> > > error = EDQUOT;
> > > g
> in summer, I posted some paravirt patches for amd64. In response to the
> comments I received then, I have created some infrastructure to binary
> patch kernel code during boot. In order to get some feedback, I am posting
> the whole paravirt & code patching diff here. Also, KVM users may be
On Wednesday 10 December 2014 00:52:44, Antoine Jacoutot wrote:
> I assume we still need this:
> printf 'change paravirt0\ny\n\n0x8\nq\n' | config -ef /bsd
> under Illumos?
Correct
//Ciphers list. It is stored after the Session ID.
const unsigned char *ciphers = hello + 44 + sessIDLen;
int ciphersLen = (ciphers[0] << 8) | ciphers[1];
ciphers += 2;
if (ciphersLen) {
const SSL_METHOD *method = SSLv3_method();
int c
On Dec 9, 2014, at 9:53 AM, David Higgs wrote:
> On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson wrote:
>>
>> I was thinking more that it might be better for sensorsd internally
>> to treat state transitions of "indicator" sensors like it treats
>> status changes, rather than change how the se
This diff converts relayd from hash32 to siphash. Relayd does not use
the hash function for an actual hash table, but can select a host based
on the hash of the source-address, destination-address and other data.
The key is generated when the hash function is first used (this may
happen in two diff
Sorry...I just realized that I forgot to check for malloc return
values. I need some sleep.
On Tue, Dec 09, 2014 at 01:14:16PM -0500, Matt Dainty wrote:
> * Ted Unangst [2014-12-08 13:28:36]:
> > On Mon, Dec 08, 2014 at 11:52, Matt Dainty wrote:
> > > * Jonathan Gray [2014-12-08 08:08:19]:
> > >>
> > >> Well any name that includes gpio that isn't taken should be fine.
> > >
> > > I wen
On Tue, Dec 09, 2014 at 10:26:13PM +, Alexey Suslikov wrote:
> Jason McIntyre kerhand.co.uk> writes:
>
> > On Tue, Dec 09, 2014 at 10:27:45PM +0200, Alexey Suslikov wrote:
> > > I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64
> kernel
> > > config doesn't do neither isapnp
On Sun, Dec 07, 2014 at 10:37:39PM -0800, William Orr wrote:
> This is a small documentation update for acpiac(4). The implmentation no
> longer seems to poll every 10 seconds, so I've removed it from the manpage.
>
fixed, thanks.
jmc
> Index: share/man/man4/acpiac.4
> ==
40 matches
Mail list logo
