On Wed, Oct 01, 2014 at 05:41:11PM -0500, Kent R. Spillner wrote:
> ok kspillner@. It would be nice to replace some of those exit(1) with
> exit(EXIT_FAILURE), but that should be a separate diff that also updates the
> err/errx's as well.
In general EXIT_XXX is frowned upon in OpenBSD.
On Wed, Oct 01, 2014 at 07:58:16PM -0700, Philip Guenther wrote:
> On Wed, Oct 1, 2014 at 4:41 PM, Daniel Dickman wrote:
> > posix commands (like ls(1) for example) keep the last option when mutually
> > exclusive options are specified.
> > does it make sense to keep rcs consistent with that con
On Wed, Oct 1, 2014 at 4:41 PM, Daniel Dickman wrote:
> posix commands (like ls(1) for example) keep the last option when mutually
> exclusive options are specified.
> does it make sense to keep rcs consistent with that convention? also is a man
> page diff needed?
RCS predates POSIX and does n
This new diff aims to simplify the mpe(4) device and also to improve
the old code that handled the installation of MPLS interface routes.
I followed what mpi@ said:
On Tue, Sep 30, 2014 at 11:00:25AM +0200, Martin Pieuchot wrote:
> Hello Rafael,
>
> On 14/09/14(Sun) 23:49, Rafael Zalamena wrote:
ok kspillner@. It would be nice to replace some of those exit(1) with
exit(EXIT_FAILURE), but that should be a separate diff that also updates the
err/errx's as well.
> On Oct 1, 2014, at 13:06, Fritjof Bornebusch wrote:
>
>> On Wed, Oct 01, 2014 at 06:41:25PM +0100, Nicholas Marriott wrote:
OTOH, check out what we do with rcs -L and -U...
On Thu, Oct 02, 2014 at 12:54:13AM +0100, Nicholas Marriott wrote:
> Matching GNU RCS seems preferable to me but I don't feel strongly about
> it.
>
> I wouldn't mention this in the man page, it hardly seems like behaviour
> anyone should (or wil
Matching GNU RCS seems preferable to me but I don't feel strongly about
it.
I wouldn't mention this in the man page, it hardly seems like behaviour
anyone should (or will need to) rely on.
On Wed, Oct 01, 2014 at 07:41:52PM -0400, Daniel Dickman wrote:
> posix commands (like ls(1) for example) k
posix commands (like ls(1) for example) keep the last option when mutually
exclusive options are specified. does it make sense to keep rcs consistent with
that convention? also is a man page diff needed?
> On Oct 1, 2014, at 7:17 PM, Nicholas Marriott
> wrote:
>
> The existing behaviour isn'
The existing behaviour isn't wildly useful, makes sense to me, ok nicm
On Wed, Oct 01, 2014 at 11:33:33PM +0200, Fritjof Bornebusch wrote:
> Hi tech,
>
> the OpenRCS rcs command produces the following output if -l and -u is
> used in the same command:
>
> $ rcs -l1.1 -u1.1 foo.txt
> RCS file:
Please do not change to EXIT_FAILURE.
Original message
From: "Kent R. Spillner"
Date: 01/10/2014 23:41 (GMT+00:00)
To: Fritjof Bornebusch
Cc: Nicholas Marriott
,tech@openbsd.org,o...@openbsd.org
Subject: Re: [Patch] use exit() directly in usage()
ok kspillner@. It wo
Hi tech,
the OpenRCS rcs command produces the following output if -l and -u is
used in the same command:
$ rcs -l1.1 -u1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
$ rcs -u1.1 -l1.1 foo.txt
RCS file: foo.txt,v
1.1 locked
1.1 unlocked
I've looked at GnuRCS and it has another way to h
On Fri, Sep 26, 2014 at 10:32:53PM -0400, thev...@openmailbox.org wrote:
> i don't know if this is considered a bug, so i sent it here instead.
>
> found this when compiling with 'option APMDEBUG':
> cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main
> -Wno-uninitialized -Wsta
On Wed, Oct 01, 2014 at 06:41:25PM +0100, Nicholas Marriott wrote:
> Looks good but you have missed out ident.c and rcsprog.c
>
Ups, sorry.
>
>
> On Wed, Oct 01, 2014 at 11:19:29AM +0200, Fritjof Bornebusch wrote:
> > On Sat, Sep 27, 2014 at 07:10:01PM +0200, Fritjof Bornebusch wrote:
> > Hi,
Looks good but you have missed out ident.c and rcsprog.c
On Wed, Oct 01, 2014 at 11:19:29AM +0200, Fritjof Bornebusch wrote:
> On Sat, Sep 27, 2014 at 07:10:01PM +0200, Fritjof Bornebusch wrote:
> Hi,
>
> > Hi,
> >
> > after usage() was called, there is no where you can go.
> >
>
> as suggest
On Wed, 1 Oct 2014, Stuart Henderson wrote:
> On 2014/10/01 19:05, Joel Sing wrote:
> > The following does this, however note that the default_bits of 1024 from
> > openssl.cnf trumps the 2048 in the define... we probably should also stop
> > making EVP_des_ede3_cbc() the default cipher...
>
> I th
On 2014/10/01 19:05, Joel Sing wrote:
> > I should also add that the other obvious/easy "fix" is to initialise digest
> > in openssl/req.c to the SHA-256 EVP. That only changes 'openssl req'
> > though.
> >
> > > (and yes, clearly I've spent too much time in this code base recently...
> > > :)
> >
On 2014/10/01 18:41, Joel Sing wrote:
> On Wed, 1 Oct 2014, Stuart Henderson wrote:
> > Over the coming months, web browsers will progressively start to first
> > warn for certificate chains including SHA-1 hashes, then treat them
> > as insecure (including disabling certain content - scripts etc).
On Sat, Sep 27, 2014 at 07:10:01PM +0200, Fritjof Bornebusch wrote:
Hi,
> Hi,
>
> after usage() was called, there is no where you can go.
>
as suggested by otto@ and @nicm, the usage() functions are marked as
__dead.
> fritjof
>
fritjof
Index: ci.c
===
> I should also add that the other obvious/easy "fix" is to initialise digest
> in openssl/req.c to the SHA-256 EVP. That only changes 'openssl req'
> though.
>
> > (and yes, clearly I've spent too much time in this code base recently...
> > :)
> >
> > > Index: openssl.cnf
> > > ===
On Wed, 1 Oct 2014, Joel Sing wrote:
> On Wed, 1 Oct 2014, Stuart Henderson wrote:
> > Over the coming months, web browsers will progressively start to first
> > warn for certificate chains including SHA-1 hashes, then treat them
> > as insecure (including disabling certain content - scripts etc).
On Wed, 1 Oct 2014, Stuart Henderson wrote:
> Over the coming months, web browsers will progressively start to first
> warn for certificate chains including SHA-1 hashes, then treat them
> as insecure (including disabling certain content - scripts etc).
> Chrome are initially doing this for certs e
21 matches
Mail list logo