On 2026/02/11 23:19, Larry Moore wrote: > In addition to these I applied changes to the Makefile and PLIST. > > In my testing late last year I found that faxgetty in HylaFAX 6.0.6 will > crash when receiving a facsimile when ECM is not negotiated during call > establishment. The same occurs in 6.0.7. > > This problem seems to go way back to OpenBSD 6.1 and possibly 6.0 but I > didn't test that version. I did test with OpenBSD 5.9 and no problems were > experienced with it. > > If you would like to discuss this further you may PM me. > > To overcome the faxgetty crash I disabled compiler optimisation;
-O0 across the whole thing is a big hammer. A backtrace might give a better clue about what's wrong to allow actually fixing it: https://www.openbsd.org/faq/ports/ports.html#Backtrace (It would be worth adding DEBUG_PACKAGES= ${BUILD_PACKAGES} to the port.) Might be worth checking if hylafax+ has fixed anything in this area before digging far though, the 'abandonware' comment in BROKEN in the current Makefile is not really wrong as far as non-+ hylafax goes. > The changes to PLIST are: > > 1) Change the permissions of libdata/hylafax/etc/hfaxd.conf > > 2) Removed libdata/hylafax/etc/xferfaxlog > > The reason behind removing xferfaxlog are two fold. Firstly, faxgetty cannot > update accounting records in this file due to the restrictive permissions; > > Feb 11 21:16:16 openbsd-78-amd64 FaxGetty[32794]: Error writing CALL > accounting record, dest=+61.REDACTED > Feb 11 21:18:24 openbsd-78-amd64 FaxGetty[32794]: Error writing RECV > accounting record, dest=+61.REDACTED > > Secondly, this file will collect historical records over time. Should the > package need to be removed for some reason this file will go - I believe > that was my experience even though it had updated records in this file after > I changed the permissions. faxgetty creates this file if it doesn't exists. I would not normally expect a port to be writing under /usr/local at runtime.. Also noticed: "@owner uucp" is no good, it will need to create its own uid. The uucp user was removed from base ~10 years ago.
