err. this is a april fool right, guys?
:-)
On Sun, Apr 1, 2012 at 1:13 PM, Nicholas Marriott
wrote:
> Can I make it wake up again automatically three days later?
>
>
> On Sun, Apr 01, 2012 at 06:35:08PM +0200, Benny Lofgren wrote:
>> On 2012-04-01 09.05, Theo de Raadt wrote:
>> > The epoch isn't
Hi,
On Sat, 31 Mar 2012 16:30:37 +0200
mxb wrote:
> looks like npppd_arp.h is missing in the tree.
>
> Is it in purpose or just a miss?
There are npppd_arp.[ch] in IIJ(upstream and company I work for)'s
local tree. But they are work-in-progress. So they should be
deleted in our tree.
--yasu
Buenos dCas, tech@openbsd.org.
Messi 10 desea invitarle a unirse a Youzzers.
Para inscribirse o visitar Youzzers, cliquez ici Youzzers - La red social
que protege su informaciC3n
Atentamente
Can I make it wake up again automatically three days later?
On Sun, Apr 01, 2012 at 06:35:08PM +0200, Benny Lofgren wrote:
> On 2012-04-01 09.05, Theo de Raadt wrote:
> > The epoch isn't far that away and we need to prepare OpenBSD for it.
> >
> > I had a little free time, so I wrote a diff to s
On Sun, Apr 01, 2012 at 01:54:10PM +0300, Paul Irofti wrote:
> [--snip-some-of-the-gyping-from-my-initial-diff--]
> > case AML_OBJTYPE_STRING:
> > - if (ival == -1)
> > + if (ival == (uint64_t)-1)
>
> This is what I tried first as well. But this cast fails on my x61s where
On 2012-04-01 09.05, Theo de Raadt wrote:
> The epoch isn't far that away and we need to prepare OpenBSD for it.
>
> I had a little free time, so I wrote a diff to simulate the behaviour
> so that we can test how parts of OpenBSD cope with it.
May I suggest a more versatile and flexible approach
runs ok on amd64.
Would test more, but it's gotten really dark for no apparent
reason. Need to check that out before someone gets hurt.
On Sun, Apr 01, 2012 at 01:05:05AM -0600, Theo de Raadt wrote:
> The epoch isn't far that away and we need to prepare OpenBSD for it.
>
> I had a little free ti
> Date: Sun, 1 Apr 2012 13:54:10 +0300
> From: Paul Irofti
>
> [--snip-some-of-the-gyping-from-my-initial-diff--]
Not really gyped. Already had some of it in my tree from when I
looked at the arithnmetic diff. It was just that your casting
mistakes made me realize what the right way to go was
[--snip-some-of-the-gyping-from-my-initial-diff--]
> case AML_OBJTYPE_STRING:
> - if (ival == -1)
> + if (ival == (uint64_t)-1)
This is what I tried first as well. But this cast fails on my x61s where
ival is set to a 32-bit -1.
> ival = strlen(
> From: Jordan Hargrave
> Date: Sun, 1 Apr 2012 08:13:13 +
>
> you will need to fix AMLOP_ONES as well. It does a (char)opcode typecast,
> which would be 0xff not 0x... if using uint64.
No, that one is fine, at least on machines where char is signed. For
AMLOP_ONES, opcode will be 0xff.
On Sun, Apr 01, 2012 at 08:13:13AM +, Jordan Hargrave wrote:
>you will need to fix AMLOP_ONES as well. It does a (char)opcode typecast,
>which would be 0xff not 0x... if using uint64.
>
>amlop_match, amlop_wait, amlop_acquire, amlop_condref all will need to
>return AML_ONE
Okay pirofti@
2012/4/1 Theo de Raadt :
> You should really re-do that so that the login name cannot start or
> end with a '.'
Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -r1.
you will need to fix AMLOP_ONES as well. It does a (char)opcode typecast,
which would be 0xff not 0x... if using uint64.
amlop_match, amlop_wait, amlop_acquire, amlop_condref all will need to return
AML_ONES or AML_TRUE
> Date: Sun, 1 Apr 2012 10:45:55 +0300
> From: p...@irofti.net
> To: o...
On Sat, Mar 31, 2012 at 05:33:33PM +0200, Otto Moerbeek wrote:
> On Sat, Mar 31, 2012 at 01:47:18AM +0300, Paul Irofti wrote:
>
> > After the report from a few weeks ago I went ahead and fixed most (if
> > not all) of the signed integer usages in the AML parser.
> >
> > Please have a look at this
On Sat, Mar 31, 2012 at 12:18:27PM +0200, Mark Kettenis wrote:
> > Date: Sat, 31 Mar 2012 01:47:18 +0300
> > From: Paul Irofti
> >
> > After the report from a few weeks ago I went ahead and fixed most (if
> > not all) of the signed integer usages in the AML parser.
> >
> > Please have a look at
The epoch isn't far that away and we need to prepare OpenBSD for it.
I had a little free time, so I wrote a diff to simulate the behaviour
so that we can test how parts of OpenBSD cope with it.
Index: sys/sysctl.h
===
RCS file: /cvs/
17 matches
Mail list logo
