Re: man, man.conf and /usr/ports/infrastructure/man

[dan mclaughlin]

On Sun, 12 Apr 2015 23:03:17 +0200 Ingo Schwarze schwa...@usta.de wrote:
 Hi,
 
 dan mclaughlin wrote on Sun, Apr 12, 2015 at 04:43:31PM -0400:
 
  it seems that /usr/ports/infrastructure/man is not searched by default,
 
 Correct.  The reason is that that directory does not even exist
 in a default OpenBSD installation.

makes perfect sense, i figured as much.

 
  and there is no example in man.conf for it.
 
 Correct, too.  I'm not opposed to adding that example.
 Your patch, as it stands, is NOT OK though, because the example
 file shows the default settings.  So at least, the line needs
 to be commented out, and a comment explaining its purpose
 might be in order, too.

i did think of that later. i was in a rush, and my intent was just to give
an example. i was expecting feedback anyway so that i better understood what
was going on.

 
  given that some pages like dpb(1) are there, and referenced
  thruout a number of pages (eg bsd.port.mk), this seems an oversight.
 
 Actually, the reason why i didn't mention it in the example file
 is that it seemed so trivial to me that i didn't expect that this
 particular example might help some people.  If it does - fair enough.

well, i was surprised not to find the manpage at first, especially when
devs kept mentioning it, but didn't look into it at the time. i finally
had a need for it, and went digging further. i found where the command was
in the faq, and made a guess where the manpages were, but i don't think it
would be that obvious to everybody. other aspect of the ports system are
in the man tarball, such as bsd.port.mk, so at first i didn't think that
there may be a special manpath for the ports system.

plus, it seems like the perfect non-standard use case to have as an example.

 
  on a releated note, it also seems that ports/infrastructure/man/mandoc.db
  is also not created by default.
 
 There is no reasonable way to include that file.  The ports tarball
 is a *source* tarball, and mandoc.db is not a source file.
 Either running makewhatis /usr/ports/infrastructure/man or
 adding it to man.conf(5) and running makewhatis is required.
 

i figured it was something like this, which is why i mentioned it as
something of an aside.

  the diff below adds a manpath to man.conf, but that still doesn't fix the
  issue of ports/infrastructure/man not being searched. perhaps this should
  be taken out of examples?
 
 No.  It was specifically decided not long ago that
 /usr/ports/infrastructure/man will not be searched by default.  If
 you want it, you have to add it manually.

fair enough, i didn't expect this was the most acceptable solition, i was
just listing the possibilities. there should be a hint though.

 
  or at least some note should be made in ports(7) or the FAQ that
  one should add this?
 
 Something like that is probably useful.

i think i found the perfect places for this in both ports(7) and the FAQ.
i'm sure the wording can be improved, but diffs below.

 
 Yours,
   Ingo
 

--- etc/examples/man.conf   Fri Mar 27 17:17:16 2015
+++ etc/examples/man.conf.new   Mon Apr 13 00:53:42 2015
@@ -8,6 +8,9 @@ manpath /usr/share/man
 manpath /usr/X11R6/man
 manpath /usr/local/man
 
+#users of the ports system may find this useful for certain ports-only commands
+#manpath /usr/ports/infrastructure/man
+
 # Options for terminal output.
 output width 78
 output indent 5



even if you don't want the mention in the intro, the listing under FILES
should be kept.

--- share/man/man7/ports.7  Sat Mar  7 07:21:55 2015
+++ share/man/man7/ports.7.new  Mon Apr 13 00:45:29 2015
@@ -72,6 +72,11 @@ Porter's Handbook
 .Pp
 For a detailed description of the build process, see
 .Xr bsd.port.mk 5 .
+.Pp
+Additional manual pages for the ports system can be located in
+.Pa /usr/ports/infrastructure/man
+(users may want to add this to their
+.Pa /etc/man.conf ) .
 .Sh PORTS MASTER MAKEFILE
 The ports master Makefile, normally located in
 .Pa /usr/ports/Makefile
@@ -727,6 +732,8 @@ Local network configuration.
 Filter list for systrace.
 .It Pa /usr/ports/infrastructure/db/user.list
 List of users and groups created by ports.
+.It Pa /usr/ports/infrastructure/man
+Path for addition ports system manual pages.
 .El
 .Sh SEE ALSO
 .Xr dpb 1 ,


--- faq15.html  Mon Apr 13 00:21:35 2015
+++ faq15.html.new  Mon Apr 13 00:28:12 2015
@@ -754,6 +754,7 @@ the use of flavors and subpackages and some other opti
 lia 
href=http://www.openbsd.org/cgi-bin/man.cgi?query=bsd.port.mkamp;sektion=5;bsd.port.mk(5)/a
 - in depth information about all the make targets, variables, the fake
 (installation directory) framework, etc.
+lithe directory /usr/ports/infrastructure/man/ also contains additional 
manual pages (users may want to add this to man.conf).
 /ul
 
 h3 id=PortsFetch15.3.2 - Fetching the ports tree/h3

Re: File protection, second attempt

[Kanonenvogel]

On 12 Apr 2015, at 21:02, Martin Pieuchot m...@openbsd.org wrote:
It's only PoF just for to show my hypothetical roadmap.
 Can you explain what need to be protected from what?
 
 1. Filelist, nfiles and operations with them are protected by rwlock.
 
 Why not, could you describe why they need a lock?  A diff just to do
 that would be much easier review.
filelist is accessed by falloc(), fdrop(), unp_gc and sysctl_file() functions. 
After
corresponding callers will be unlocked, their calls and filelist 
modifications/reading
become asynchronous, so filelist need to be protected.

I want to have read value - or/and - store value chain not be broken by
races, so f_iflags and f_flag operations are atomic.
 
 2. Garbage collector's flags FIF_MARK and FIF_DEFER moved from f_iflags to
 new field f_gc_flags (compatibility with pstat was kept).
 
 Why did you decide to split f_iflags in two?  What's the problem this
 move is solving?  Here too a diff just to do that would be much easier
 to review.
Those flags exists only for sockets. I suppose they can be moved out from
struct file but later. Those flags are modified/accessed in only one mp locked
place, so they does'n need any protection now, and their modification doesn't
affect on FIF_LARVAL and FIF_HASLOCK flags.

 3. Operations over f_iflags are atomic. FIF_LARVAL set only once and
 FIF_HASLOCK isn't set too frequent.
 
 Why are you using atomic operations for these flags?  Which scenario
 that would help?   Did you consider any alternative?

FIF_LARVAL looks unnecessary, because file can become mature after
f_ops field was set. Of course it is just assignment and it can be non-atomic.
But now, there are some places, there f_ops methods called before FIF_LARVAL
flag is set, so if FIF_LARVAL will gone, they should be rewritten before.
FIF_HASLOCK can be removed too. it checked only in vn_closefile(), but this flag
doesn’t indicate actual vnode lock state, because VOP_ADVLOCK()’s return value
is not checked. May be it can be replaced by new vn_islocked() function, which 
will
check actual vnode lock possibility and lock state?
 
 4. Set/unset operations over f_flag are atomic. They are not too frequent.
 
 Does that mean that as soon as the atomic operation has completed all the
 conditions that a flag represent are true/false?  Since the integrity of
 the code you're changing is currently protected by the biglock the order
 of the operations inside the functions does not really matter.   Setting
 the flag atomically is in generally not enough and since you're not
 giving more details it's hard to dig into a huge diff ;)
I want only f_flag consistence. mp locked related code must be reviewed later.

 5. Operations over f_count are atomic. Surely those are frequent though they
 can be non atomic on uniprocessor kernel.
 
 Why do they need to be atomic and also why are you doing a dance with
 the file_lock when you cannot increment the counter?
fd_getfile_ref() has not any lock inside, so we have races with callers,
which modify f_count.
I want to have new value, incremented by 1 with previously known non-null
value to avoid funref()/fd_gerfile_ref() races. If I can't increment counter, 
then
it has been modified by someone else, so I re-check it's presence in fd_ofiles 
array,
it's reference counter != 0 and if this fp was acqured, I check it's place in
fd_ofiles again; fp != fp_ofiles[fd] means fp_ofiles[fd] was modified, fp 
actually
was closed, and I should release it and try to acquire new file with given fd.

 6. f_offset field is not protectd now, it should be protected later.
 
 From what should it be protected?
Async dofilereadv(), dofilewritev() and sys_lseek() calls will modify this 
field.
Also, off_t is 64bit and it should be protected for reading on 32bit 
architectures.

 
 7. Counters are not protected now, they should be protected later.
 
 Same question :)
Same answer :) they are 64 bits and modify/read by async calls.

 
 Since I've been lurking in that area too recently, you'll find 5
 refactoring diffs attached to this email.  It's easier for me to
 send you the work that I did rather than comment on some things.
I understand and agree with 0002, 0003, 0004 and 0005.
I don't understand, why we need to check flags inside fd_getfile.

 One more question, did you consider the fact that the code you're
 modifying might contain some bugs which are currently not exposed
 because most of it is run under the KERNEL_LOCK?
Yes, of course. It can be painful process :)

Re: VXLAN with a private address on the external interface

[Rob wylde]

*Private*
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
default10.42.0.1  UGS9   435365 - 8 em0
10.1.1.108 10.1.1.108 UHl00 32768 1 lo0
10.42.0/24 link#1 UC 30 - 4 em0
10.42.0.1  00:24:e8:1d:4b:ca  UHLc   2   19 - 4 em0
10.42.0.103ba:18:9d:1e:b7:fc  UHLc   161948 - 4 em0
10.42.0.13776:25:1c:0f:e2:96  UHLc   00 - 4 em0
10.42.0.14000:00:24:d0:62:10  UHLl   00 - 1 lo0
10.42.0.255link#1 UHLb   00 - 1 em0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHl10 32768 1 lo0
224/4  127.0.0.1  URS00 32768 8 lo0

*Public*
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
default108.181.x.x   UGS8   70 - 8 em0
10.1.1.108 10.1.1.108 UHl00 32768 1 lo0
108.181.x/22  link#1 UC 10 - 4 em0
108.181.x.x  0c:a4:02:23:f5:96  UHLc   10 - 4 em0
108.181.x.x 00:00:24:d0:62:10  UHLl   00 - 1 lo0
108.181.x.255 link#1 UHLb   00 - 1 em0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHl10 32768 1 lo0
224/4  127.0.0.1  URS00 32768 8 lo0

No other changes aside from 'switchmode access vlan x' and issuing a reboot
on the client side device once it comes back online with a public address
my IPTV flows perfectly.
I'm also now updating to -current and applying
http://marc.info/?l=openbsd-techm=142867514829648w=2 and hoping for the
best

Thanks for the response

On Sun, Apr 12, 2015 at 12:22 AM, Stuart Henderson st...@openbsd.org
wrote:

 On 2015/04/11 20:35, Rob wylde wrote:
  Here is my possibly poorly written bugreport
 
  http://marc.info/?l=openbsd-bugsm=142856496830537w=2
  I also have port 4789 udp open
 
  I've since posting that discovered that if I give my client box a public
 IP
  it works flawlessly. The instant I flip it back to private
  functionality deteriorate's( unicast works but multicast completely fails
  ). Between flipping of networks I destroy and rebuild the vxlan and
 bridge
  on the server side and usually for good measure completely reboot the
  client.
 
  Any suggestions would be helpful
 
  Thanks

 It seems unlikely that this would be about the exact IP addresses in use.
 Is that the only change or is there some other change (maybe routes; do you
 have a default route in one case, and not in the other)?

Re: VXLAN with a private address on the external interface

[Stuart Henderson]

On 2015/04/11 20:35, Rob wylde wrote:
 Here is my possibly poorly written bugreport
 
 http://marc.info/?l=openbsd-bugsm=142856496830537w=2
 I also have port 4789 udp open
 
 I've since posting that discovered that if I give my client box a public IP
 it works flawlessly. The instant I flip it back to private
 functionality deteriorate's( unicast works but multicast completely fails
 ). Between flipping of networks I destroy and rebuild the vxlan and bridge
 on the server side and usually for good measure completely reboot the
 client.
 
 Any suggestions would be helpful
 
 Thanks

It seems unlikely that this would be about the exact IP addresses in use.
Is that the only change or is there some other change (maybe routes; do you
have a default route in one case, and not in the other)?

File protection, second attempt

[Kanonenvogel]

This is the second attempt of struct file protection.

1. Filelist, nfiles and operations with them are protected by rwlock.
2. Garbage collector's flags FIF_MARK and FIF_DEFER moved from f_iflags to
new field f_gc_flags (compatibility with pstat was kept).
3. Operations over f_iflags are atomic. FIF_LARVAL set only once and
FIF_HASLOCK isn't set too frequent.
4. Set/unset operations over f_flag are atomic. They are not too frequent.
5. Operations over f_count are atomic. Surely those are frequent though they
can be non atomic on uniprocessor kernel.
6. f_offset field is not protectd now, it should be protected later.
7. Counters are not protected now, they should be protected later.

For test purpose, I moved out sys_close, sys_closefrom, sys_dup, sys_dup2
and sys_dup3 from kernel lock, except little mp locked fragments. I also
moved out sys_read, sys_readv, sys_pread, sys_preadv, sys_write, sys_writev,
sys_pwrite and sys_pwritev syscalls from kernel lock (dofilereadv() and
dofilewritev() are mp locked, of course) for struct file object
capture/release purpose. With this modifications my system rebuilds kernel
in multiple instenses simultaneously.

Index: arch/i386/i386/linux_machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/linux_machdep.c,v
retrieving revision 1.46
diff -u -p -r1.46 linux_machdep.c
--- arch/i386/i386/linux_machdep.c  16 Dec 2014 18:30:03 -  1.46
+++ arch/i386/i386/linux_machdep.c  12 Apr 2015 01:27:22 -
@@ -440,8 +440,12 @@ linux_machdepioctl(struct proc *p, void 
com = SCARG(uap, com);
 
fdp = p-p_fd;
-   if ((fp = fd_getfile(fdp, fd)) == NULL)
+   fdplock(fdp);
+   if (fd_getfile(fdp, fd) == NULL) {
+   fdpunlock(fdp);
return (EBADF);
+   }
+   fdpunlock(fdp);
 
switch (com) {
 #if (NWSDISPLAY  0  defined(WSDISPLAY_COMPAT_USL))
@@ -568,12 +572,13 @@ linux_machdepioctl(struct proc *p, void 
 * XXX hack: if the function returns EJUSTRETURN,
 * it has stuffed a sysctl return value in pt.data.
 */
-   FREF(fp);
+   if ((fp = fd_getfile_ref(fdp, fd, p)) == NULL)
+   return (EBADF);
ioctlf = fp-f_ops-fo_ioctl;
pt.com = SCARG(uap, com);
pt.data = SCARG(uap, data);
error = ioctlf(fp, PTIOCLINUX, (caddr_t)pt, p);
-   FRELE(fp, p);
+   funref(fp, p);
if (error == EJUSTRETURN) {
retval[0] = (register_t)pt.data;
error = 0;
Index: compat/linux/linux_blkio.c
===
RCS file: /cvs/src/sys/compat/linux/linux_blkio.c,v
retrieving revision 1.9
diff -u -p -r1.9 linux_blkio.c
--- compat/linux/linux_blkio.c  22 Apr 2012 05:43:14 -  1.9
+++ compat/linux/linux_blkio.c  12 Apr 2015 01:28:20 -
@@ -70,9 +70,8 @@ linux_ioctl_blkio(struct proc *p, struct
struct disklabel label;
 
 fdp = p-p_fd;
-   if ((fp = fd_getfile(fdp, SCARG(uap, fd))) == NULL)
+   if ((fp = fd_getfile_ref(fdp, SCARG(uap, fd), p)) == NULL)
return (EBADF);
-   FREF(fp);
error = 0;
ioctlf = fp-f_ops-fo_ioctl;
com = SCARG(uap, com);
@@ -118,6 +117,6 @@ linux_ioctl_blkio(struct proc *p, struct
error = ENOTTY;
}
 
-   FRELE(fp, p);
+   funref(fp, p);
return error;
 }
Index: compat/linux/linux_cdrom.c
===
RCS file: /cvs/src/sys/compat/linux/linux_cdrom.c,v
retrieving revision 1.11
diff -u -p -r1.11 linux_cdrom.c
--- compat/linux/linux_cdrom.c  26 Mar 2014 05:23:42 -  1.11
+++ compat/linux/linux_cdrom.c  12 Apr 2015 01:28:20 -
@@ -108,9 +108,8 @@ linux_ioctl_cdrom(p, v, retval)
 
 
fdp = p-p_fd;
-   if ((fp = fd_getfile(fdp, SCARG(uap, fd))) == NULL)
+   if ((fp = fd_getfile_ref(fdp, SCARG(uap, fd), p)) == NULL)
return (EBADF);
-   FREF(fp);
 
if ((fp-f_flag  (FREAD | FWRITE)) == 0) {
error = EBADF;
@@ -293,6 +292,6 @@ linux_ioctl_cdrom(p, v, retval)
error = sys_ioctl(p, ia, retval);
 
 out:
-   FRELE(fp, p);
+   funref(fp, p);
return (error);
 }
Index: compat/linux/linux_fdio.c
===
RCS file: /cvs/src/sys/compat/linux/linux_fdio.c,v
retrieving revision 1.7
diff -u -p -r1.7 linux_fdio.c
--- compat/linux/linux_fdio.c   22 Apr 2012 05:43:14 -  1.7
+++ compat/linux/linux_fdio.c   12 Apr 2015 01:28:20 -
@@ -75,10 +75,9 @@ linux_ioctl_fdio(struct proc *p, struct 
com = (u_long)SCARG(uap, data);
 
fdp = p-p_fd;
-   if ((fp = fd_getfile(fdp, SCARG(uap, fd))) == NULL)
+   if ((fp = fd_getfile_ref(fdp, SCARG(uap, fd), p)) == 

man EVP_EncryptInit: Two small errors

[Max Fillinger]

It's out, not outl, that needs to contain sufficient room. Also, add a
pair of parentheses to mark EVP_DecryptInit_ex as a function.

Index: lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
===
RCS file: /cvs/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod,v
retrieving revision 1.13
diff -u -p -r1.13 EVP_EncryptInit.pod
--- lib/libssl/src/doc/crypto/EVP_EncryptInit.pod   11 Jul 2014 16:18:14 
-  1.13
+++ lib/libssl/src/doc/crypto/EVP_EncryptInit.pod   12 Apr 2015 12:45:13 
-
@@ -124,7 +124,7 @@ writes the encrypted version to Bout. 
 multiple times to encrypt successive blocks of data. The amount
 of data written depends on the block alignment of the encrypted data:
 as a result the amount of data written may be anything from zero bytes
-to (inl + cipher_block_size - 1) so Boutl should contain sufficient
+to (inl + cipher_block_size - 1) so Bout should contain sufficient
 room. The actual number of bytes written is placed in Boutl.
 
 If padding is enabled (the default) then EVP_EncryptFinal_ex() encrypts
@@ -160,7 +160,7 @@ after all operations using a cipher are 
 does not remain in memory.
 
 EVP_EncryptInit(), EVP_DecryptInit() and EVP_CipherInit() behave in a
-similar way to EVP_EncryptInit_ex(), EVP_DecryptInit_ex and
+similar way to EVP_EncryptInit_ex(), EVP_DecryptInit_ex() and
 EVP_CipherInit_ex() except the Bctx parameter does not need to be
 initialized and they always use the default cipher implementation.
 

Re: File protection, second attempt

[Martin Pieuchot]

Hello,

This is an interesting diff with a lot of stuff in it.  I'd suggest
you to give more details about what you're trying to achieve with it
and split it into small parts.

It's nice to see some work done in this area, but do not rush you'd be
surprise by the dragons in there.

On 12/04/15(Sun) 15:19, Kanonenvogel wrote:
 This is the second attempt of struct file protection.

Can you explain what need to be protected from what?

 1. Filelist, nfiles and operations with them are protected by rwlock.

Why not, could you describe why they need a lock?  A diff just to do
that would be much easier review.

 2. Garbage collector's flags FIF_MARK and FIF_DEFER moved from f_iflags to
 new field f_gc_flags (compatibility with pstat was kept).

Why did you decide to split f_iflags in two?  What's the problem this
move is solving?  Here too a diff just to do that would be much easier
to review.

 3. Operations over f_iflags are atomic. FIF_LARVAL set only once and
 FIF_HASLOCK isn't set too frequent.

Why are you using atomic operations for these flags?  Which scenario
that would help?   Did you consider any alternative?

 4. Set/unset operations over f_flag are atomic. They are not too frequent.

Does that mean that as soon as the atomic operation has completed all the
conditions that a flag represent are true/false?  Since the integrity of
the code you're changing is currently protected by the biglock the order
of the operations inside the functions does not really matter.   Setting
the flag atomically is in generally not enough and since you're not
giving more details it's hard to dig into a huge diff ;)

 5. Operations over f_count are atomic. Surely those are frequent though they
 can be non atomic on uniprocessor kernel.

Why do they need to be atomic and also why are you doing a dance with
the file_lock when you cannot increment the counter?

 6. f_offset field is not protectd now, it should be protected later.

From what should it be protected?

 7. Counters are not protected now, they should be protected later.

Same question :)

Since I've been lurking in that area too recently, you'll find 5
refactoring diffs attached to this email.  It's easier for me to
send you the work that I did rather than comment on some things.

One more question, did you consider the fact that the code you're
modifying might contain some bugs which are currently not exposed
because most of it is run under the KERNEL_LOCK?
From d7b381d438aa98a80e66c4aceeb905ef0a3ab9f3 Mon Sep 17 00:00:00 2001
From: Martin Pieuchot m...@openbsd.org
Date: Mon, 2 Mar 2015 16:33:04 +0100
Subject: [PATCH 1/5] Check for flags inside fd_getfile(), will help for
 upcoming locking.

---
 sys/arch/i386/i386/linux_machdep.c |  2 +-
 sys/compat/linux/linux_blkio.c |  2 +-
 sys/compat/linux/linux_cdrom.c |  7 +--
 sys/compat/linux/linux_fdio.c  |  2 +-
 sys/compat/linux/linux_file.c  |  4 ++--
 sys/compat/linux/linux_hdio.c  |  2 +-
 sys/compat/linux/linux_socket.c|  2 +-
 sys/compat/linux/linux_termios.c   |  7 +--
 sys/compat/ossaudio/ossaudio.c | 19 +++
 sys/dev/systrace.c |  2 +-
 sys/kern/kern_descrip.c| 23 +--
 sys/kern/kern_event.c  |  4 ++--
 sys/kern/kern_exec.c   |  2 +-
 sys/kern/sys_generic.c | 27 +++
 sys/kern/uipc_syscalls.c   |  2 +-
 sys/kern/uipc_usrreq.c |  2 +-
 sys/kern/vfs_lookup.c  |  2 +-
 sys/kern/vfs_syscalls.c| 22 +++---
 sys/miscfs/fuse/fuse_vfsops.c  |  2 +-
 sys/sys/filedesc.h |  2 +-
 sys/uvm/uvm_mmap.c |  2 +-
 21 files changed, 49 insertions(+), 90 deletions(-)

diff --git sys/arch/i386/i386/linux_machdep.c sys/arch/i386/i386/linux_machdep.c
index 3ada48c..e5ee44e 100644
--- sys/arch/i386/i386/linux_machdep.c
+++ sys/arch/i386/i386/linux_machdep.c
@@ -440,7 +440,7 @@ linux_machdepioctl(struct proc *p, void *v, register_t 
*retval)
com = SCARG(uap, com);
 
fdp = p-p_fd;
-   if ((fp = fd_getfile(fdp, fd)) == NULL)
+   if ((fp = fd_getfile(fdp, fd, 0)) == NULL)
return (EBADF);
 
switch (com) {
diff --git sys/compat/linux/linux_blkio.c sys/compat/linux/linux_blkio.c
index 287ae3c..860b1af 100644
--- sys/compat/linux/linux_blkio.c
+++ sys/compat/linux/linux_blkio.c
@@ -70,7 +70,7 @@ linux_ioctl_blkio(struct proc *p, struct linux_sys_ioctl_args 
*uap,
struct disklabel label;
 
 fdp = p-p_fd;
-   if ((fp = fd_getfile(fdp, SCARG(uap, fd))) == NULL)
+   if ((fp = fd_getfile(fdp, SCARG(uap, fd), 0)) == NULL)
return (EBADF);
FREF(fp);
error = 0;
diff --git sys/compat/linux/linux_cdrom.c sys/compat/linux/linux_cdrom.c
index b1ca8e1..b00fdfc 100644
--- sys/compat/linux/linux_cdrom.c
+++ sys/compat/linux/linux_cdrom.c
@@ -108,15 +108,10 @@ linux_ioctl_cdrom(p, v, retval)
 
 

man, man.conf and /usr/ports/infrastructure/man

[dan mclaughlin]

it seems that /usr/ports/infrastructure/man is not searched by default, and
there is no example in man.conf for it. given that some pages like dpb(1)
are there, and referenced thruout a number of pages (eg bsd.port.mk), this
seems an oversight.

on a releated note, it also seems that ports/infrastructure/man/mandoc.db
is also not created by default.

the diff below adds a manpath to man.conf, but that still doesn't fix the
issue of ports/infrastructure/man not being searched. perhaps this should
be taken out of examples? or at least some note should be made in ports(7)
or the FAQ that one should add this? many regular manpages reference it,
and 'man dpb' never works by default.

--- etc/examples/man.conf   Fri Mar 27 17:17:16 2015
+++ etc/examples/man.conf.new   Sun Apr 12 16:24:55 2015
@@ -7,6 +7,7 @@
 manpath /usr/share/man
 manpath /usr/X11R6/man
 manpath /usr/local/man
+manpath /usr/ports/infrastructure/man
 
 # Options for terminal output.
 output width 78

Re: man EVP_EncryptInit: Two small errors

[Jason McIntyre]

On Sun, Apr 12, 2015 at 02:47:41PM +0200, Max Fillinger wrote:
 It's out, not outl, that needs to contain sufficient room. Also, add a
 pair of parentheses to mark EVP_DecryptInit_ex as a function.
 

these docs are getting (steadily) converted to mdoc. i think we could
just wait and get the converter to fold them in.

jmc

 Index: lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
 ===
 RCS file: /cvs/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod,v
 retrieving revision 1.13
 diff -u -p -r1.13 EVP_EncryptInit.pod
 --- lib/libssl/src/doc/crypto/EVP_EncryptInit.pod 11 Jul 2014 16:18:14 
 -  1.13
 +++ lib/libssl/src/doc/crypto/EVP_EncryptInit.pod 12 Apr 2015 12:45:13 
 -
 @@ -124,7 +124,7 @@ writes the encrypted version to Bout. 
  multiple times to encrypt successive blocks of data. The amount
  of data written depends on the block alignment of the encrypted data:
  as a result the amount of data written may be anything from zero bytes
 -to (inl + cipher_block_size - 1) so Boutl should contain sufficient
 +to (inl + cipher_block_size - 1) so Bout should contain sufficient
  room. The actual number of bytes written is placed in Boutl.
  
  If padding is enabled (the default) then EVP_EncryptFinal_ex() encrypts
 @@ -160,7 +160,7 @@ after all operations using a cipher are 
  does not remain in memory.
  
  EVP_EncryptInit(), EVP_DecryptInit() and EVP_CipherInit() behave in a
 -similar way to EVP_EncryptInit_ex(), EVP_DecryptInit_ex and
 +similar way to EVP_EncryptInit_ex(), EVP_DecryptInit_ex() and
  EVP_CipherInit_ex() except the Bctx parameter does not need to be
  initialized and they always use the default cipher implementation.
  
 

Re: man, man.conf and /usr/ports/infrastructure/man

[Landry Breuil]

On Sun, Apr 12, 2015 at 04:43:31PM -0400, dan mclaughlin wrote:
 it seems that /usr/ports/infrastructure/man is not searched by default, and
 there is no example in man.conf for it. given that some pages like dpb(1)
 are there, and referenced thruout a number of pages (eg bsd.port.mk), this
 seems an oversight.
 
 on a releated note, it also seems that ports/infrastructure/man/mandoc.db
 is also not created by default.
 
 the diff below adds a manpath to man.conf, but that still doesn't fix the
 issue of ports/infrastructure/man not being searched. perhaps this should
 be taken out of examples? or at least some note should be made in ports(7)
 or the FAQ that one should add this? many regular manpages reference it,
 and 'man dpb' never works by default.

It was the case before but was removed in src/etc/man.conf r1.22.

Landry

Re: man, man.conf and /usr/ports/infrastructure/man

[Ingo Schwarze]

Hi,

dan mclaughlin wrote on Sun, Apr 12, 2015 at 04:43:31PM -0400:

 it seems that /usr/ports/infrastructure/man is not searched by default,

Correct.  The reason is that that directory does not even exist
in a default OpenBSD installation.

 and there is no example in man.conf for it.

Correct, too.  I'm not opposed to adding that example.
Your patch, as it stands, is NOT OK though, because the example
file shows the default settings.  So at least, the line needs
to be commented out, and a comment explaining its purpose
might be in order, too.

 given that some pages like dpb(1) are there, and referenced
 thruout a number of pages (eg bsd.port.mk), this seems an oversight.

Actually, the reason why i didn't mention it in the example file
is that it seemed so trivial to me that i didn't expect that this
particular example might help some people.  If it does - fair enough.

 on a releated note, it also seems that ports/infrastructure/man/mandoc.db
 is also not created by default.

There is no reasonable way to include that file.  The ports tarball
is a *source* tarball, and mandoc.db is not a source file.
Either running makewhatis /usr/ports/infrastructure/man or
adding it to man.conf(5) and running makewhatis is required.

 the diff below adds a manpath to man.conf, but that still doesn't fix the
 issue of ports/infrastructure/man not being searched. perhaps this should
 be taken out of examples?

No.  It was specifically decided not long ago that
/usr/ports/infrastructure/man will not be searched by default.  If
you want it, you have to add it manually.

 or at least some note should be made in ports(7) or the FAQ that
 one should add this?

Something like that is probably useful.

Yours,
  Ingo

 many regular manpages reference it,
 and 'man dpb' never works by default.
 
 --- etc/examples/man.conf Fri Mar 27 17:17:16 2015
 +++ etc/examples/man.conf.new Sun Apr 12 16:24:55 2015
 @@ -7,6 +7,7 @@
  manpath /usr/share/man
  manpath /usr/X11R6/man
  manpath /usr/local/man
 +manpath /usr/ports/infrastructure/man
  
  # Options for terminal output.
  output width 78