HylaFAX HylaFAX+ Code Repository

Patch from FreeBSD ports at:

http://svnweb.freebsd.org/ports/head/comms/hylafax/files/patch-hylafax.in

Adds an HFAXD_ARGS option.

This is one part of a FreeBSD utmpx patch from:

http://svnweb.freebsd.org/ports/head/comms/hylafax/files/patch-GettySysV.c%2B%2B

The other part of the patch seems a hack instead of a fix, and so omitting that.

Ghostscript has removed pswrite device.

Because some versions of the ps2write device were buggy we now need to detect whether or not the pswrite device is available and act accordingly.

If at some point we learn which versions of Ghostscript have the buggy ps2write device then we could default to ps2write except for those versions.

This removes CONFIG_FIFOBUG and CONFIG_OPENFIFO workarounds for a sanctioned approach.

This was a result of a conversation on hylafax-users@... between Daren Russell, Konstantin Belousov, and myself. Daren was encountering problems with fast-looping in faxgetty on select() and read() calls. This appears to happen do to a change in FreeBSD on how select() works.

Looking into things, it appears that HylaFAX has been relying on a bug in the select() implementation as a feature to avoid EOF detection. Over the years as various UNIXes have dealt with this matter HylaFAX has apparently attempted to cope by relying on other undefined behaviors (such as read+write on a FIFO).

The sanctioned approach to avoid EOF is to have the reading process additionally open up the FIFO in write-only... and then do nothing with it other than leaving it open.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166071
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=94772
http://fixunix.com/unix/350803-use-select-fifo-after-has-closed.html

Update config.guess and config.sub.

This adds a "probeonly" feature typically to be used in probing the accessibility or functionality of a receiver and not to transmit any fax documents.

An example session crashed after a Phase C session which detected corrupt data
was followed by PPS-NULL and then the subsequent Phase C session detected no
data at all and was also followed with PPS-NULL. This fixes the reason for the
segfault as well as the mistake of counting that corrupt data in a PPR-NULL-
terminated Phase C session to be "1" frame instead of "0".

When submitting a job group the docq files are shared in-common with all of the jobs in the group. This stops faxq from deleting the shared docq files and leaves that to faxqclean.

The changes made in revision R2258 seem to have been overzealous.

FaxQueuer expects the sendq file to remain in-place for longer or we'll get "job file vanished" complaints. Furthermore, a report seems to allude to this change being the catalyst to faxq crashing when the conditions are right.

This modifies the changes from R2258 to function as before except with the additional logging provided by R2258.

Detect RING/CALLEDPARTYNUMBER presentation... from OpenSuSE patches. Also adds logging of CallID.