[MacPorts] #59397: openssh @8.1_1: fails to build on 10.6: audit-bsm.c:66:10: fatal error: 'bsm/audit_session.h' file not found

[MacPorts]

#59397: openssh @8.1_1: fails to build on 10.6: audit-bsm.c:66:10: fatal error:
'bsm/audit_session.h' file not found
-------------------------+----------------------------------------
  Reporter:  grumpybozo  |      Owner:  Ionic
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.6.1
Resolution:  fixed       |   Keywords:  snowleopard lion legacy-os
      Port:  openssh     |
-------------------------+----------------------------------------

Comment (by iEFdev):

 Replying to [comment:37 Ionic]:
 > That highly depends on where the key is coming from. If it came via ssh-
 agent, then that only tells us that the running ssh-agent either has the
 key already cached or can read the keychain. The running ssh-agent is
 typically the Apple-/system-provided one, though, and not the one
 installed via MacPorts, so this would be testing something completely
 different. If the key came from a file directly, neither an agent nor the
 keychain would have been involved either (maybe minus a passphrase stored
 within the keychain, iff the private key was encrypted).

 Yes, the access might be from the builtin one. I don't think it's cached
 (at the time). I ran a restart before, (actually a safe start and then a
 restart). I don't have any passwordless keys. I always make the key(s)
 with a long password (128, gen by KeePassX) and then add it to keychain
 and then setup an ssh shortcut to use with it //(eg `ssh mySrv`)//. And of
 course, one key per login.

 [[br]]


 > Hm, I can't tell right now. `man` itself shouldn't be caching anything
 as far as I remember, but I don't know what `open` does with an `x-man-
 page` URL.

 `open x-man-page://<prog>`, is what happens when you right-click on `port`
 (for example) inside the terminal window, and chose “Open man Page” and it
 opens up in a new window. // (I use it with a function instead, to be able
 stay on the keyboard.)

 It's was probably a `MANPATH` issue.  I cleared it out today. Had some old
 paths that might could've interfered. It shows the same man page in both
 now.

 [[br]]

 > Today's date isn't surprising, because that's when the man page was
 built. So at least that should be normal. It should, theoretically, be
 different tomorrow.

 No, the date wasn't surpring, but it was with the same date on both -
 since one of them is showing the old one. Actually, today it show todays
 date: Oct 27,  2019. Even though the date is set in the file to: `.Dd
 $Mdocdate: January 21 2019 $`. Found
 [https://unix.stackexchange.com/questions/430344/why-does-this-man-page-
 have-todays-date#432252 this post], and it seems like that is a bug with
 the macro expansion. Installed `groff` and now it shows the correct date.

 [[br]]

 > I can't reproduce that on 10.9 though, and if even 10.7 uses
 `/usr/include/security`, there's probably no sense in keeping that around.
 Not sure about 10.6 and specifically 10.5 and 10.4, though. Apple might
 have moved things to `security` with 10.6 or something like that.

 Yes, 10.6+ seems right. [https://stackoverflow.com/questions/21149481
 /fails-to-build-yaws-on-mac-os-x-10-9#21164465 This one] suggests that to.

-- 
Ticket URL: <https://trac.macports.org/ticket/59397#comment:38>
MacPorts <https://www.macports.org/>
Ports system for macOS