On Sat, Sep 15, 2018 at 09:42:47PM -0400, Matt Schwartz wrote:
> Damnit! I forgot one line. Please disregard the previous. Now all
> lines of mailer.conf(5) should reflect that sendmail is no longer in
> the default install.
>
i'm ok with this, though the spacing on your diff got mangled and it
d
On Sat, Sep 15, 2018, Matt Schwartz wrote:
> reflect that the sendmail binary would be in
> /usr/local/libexec/sendmail instead of /usr/libexec/sendmail.
In that case you might want to change the comment too
(or simply remove it...)
> # Execute the "real" sendmail program, named /usr/libexec/se
I'm generally opposed to breaking stdout compatibility with the
"openssl" command tools because we have no clue what shell scripts and
other applications this will break.
with a *very good reason* I think it's ok, but this (I think this
looks better) isn't one of them. the "openssl" command is ke
On Sat, Sep 15, 2018 at 11:59 AM David Higgs wrote:
> I often use VirtualBox (version 5.2.18 on OS X) to familiarize myself
> with new features in snapshots, before upgrading my physical hardware.
>
> This afternoon, I tried updating bsd.rd (amd64, 6.4-beta RAMDISK_CD
> #281) and wasn't able to s
Damnit! I forgot one line. Please disregard the previous. Now all
lines of mailer.conf(5) should reflect that sendmail is no longer in
the default install.
Index: mailer.conf.5
===
RCS file: /cvs/src/usr.sbin/mailwrapper/mailer.conf.5
Quick correction to the mailer.conf(5) man page. Since sendmail is no
longer in the default install, the man page has been corrected to
reflect that the sendmail binary would be in
/usr/local/libexec/sendmail instead of /usr/libexec/sendmail.
Index: mailer.conf.5
==
I often use VirtualBox (version 5.2.18 on OS X) to familiarize myself
with new features in snapshots, before upgrading my physical hardware.
This afternoon, I tried updating bsd.rd (amd64, 6.4-beta RAMDISK_CD
#281) and wasn't able to successfully boot it. I had to rely on the
video capture abilit
Bump.
On Tue, Aug 28, 2018 at 10:33:34AM -0500, Scott Cheloha wrote:
> Two diffs here.
>
> First, move the tally mark printing out of the benchmark loop.
>
> Second, print '0' for TLS 1.0, '1' for TLS 1.1, etc.
>
> This breaks stdout compatibility with OpenSSL s_time, and prior
> versions of s_
On Sat, Sep 15, 2018 at 06:33:47AM -0600, Todd C. Miller wrote:
> We can use uid_from_user(3) and gid_from_group(3) in utilities that
> do repeated passwd/group lookups.
>
> This is the final diff.
ok tb
On Thu, Sep 13, 2018 at 11:02:17AM -0600, Todd C. Miller wrote:
> Use user_from_uid(3) and group_from_gid(3) in a few more places
> that do repeated lookups.
ok tb
On Thu, Sep 13, 2018 at 10:48:15AM -0600, Todd C. Miller wrote:
> Use user_from_uid(3) and group_from_gid(3) to avoid extra passwd
> and group file lookups. This required a bit of reordering of the
> file mode handling bits to deal with the const char *.
ok tb
On Sat, Sep 15, 2018 at 06:16:42AM -0600, Todd C. Miller wrote:
> On Sat, 15 Sep 2018 12:42:22 +0200, Martijn van Duren wrote:
>
> > While here, should we also remove any in favour of strchr? Only
> > difference seems to be the return type (bool vs pointer).
>
> Note that any(NULL, ch) is safe wh
On Thu, Sep 13, 2018 at 02:15:34PM -0600, Todd C. Miller wrote:
> On Thu, 13 Sep 2018 10:47:35 -0600, "Todd C. Miller" wrote:
>
> > Use the passwd/group cache functions in mtree(1) to avoid repeatedly
> > looking up the same user/group. The passwd and group files are
> > kept open too.
>
> I sen
On Thu, Sep 13, 2018 at 10:35:11AM -0600, Todd C. Miller wrote:
> Replace the local getname() and getuserid() functions with calls
> to user_from_uid(3) and uid_from_user(3). This requires sprinkling
> const in a few places but is otherwise mechanical.
ok tb
We can use uid_from_user(3) and gid_from_group(3) in utilities that
do repeated passwd/group lookups.
This is the final diff.
- todd
Index: bin/chmod/chmod.c
===
RCS file: /cvs/src/bin/chmod/chmod.c,v
retrieving revision 1.42
diff
On Sat, 15 Sep 2018 12:42:22 +0200, Martijn van Duren wrote:
> While here, should we also remove any in favour of strchr? Only
> difference seems to be the return type (bool vs pointer).
Note that any(NULL, ch) is safe whereas strchr(NULL, ch) will crash.
It is hard to say whether or not there ar
On 09/14/18 16:30, Michael Mikonos wrote:
> On Sat, Sep 08, 2018 at 10:13:35AM +0200, Martijn van Duren wrote:
>> On 09/08/18 04:57, Michael Mikonos wrote:
>>> Hello,
>>>
>>> The function strsave() in csh(1) is practically strdup(3).
>>> The only difference is memory allocation failure results in
>
17 matches
Mail list logo