I'm not sure if this causes issues with Hylafax < 4.2 but the forced 3.6 upgrade broke hylafax. Specifically tiff2ps. It gives Integer overflow in TIFFVTileSize on every fax we received. I had to hunt down an old ebuild for 3.5.7 to get it working again. This seems to be a known issue but according to bugzilla, it was tested before pushed out. I'd make a sample tiff available to someone but the faxes we receive have confidential information on them. I can't let that out.
I confirm that it also breaks hylafax 4.1.8, with exactly the same errors.
I believe that this bug is discussed at http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=500 Along with a patch. Any chance we can get this in a new ebuild of tiff?
I would say a better solution is to get either a 3.6.1 ebuild of tiff as suggested (that seems to have the problem fixed) or possibly include a version of libtiff WITH hylafax that it can be linked against statically. I actually prefere the second method. All this server does is recieve faxes. I have no problem with having a statically built version of libtiff and then a version installed that the local CUPS instance can use.
Created attachment 42252 [details] tiff-3.7.0.ebuild upgrading to libtiff 3.7 works for me (only tested with hylafax-4.2.0) NB <=hylafax-4.2.0 wont rebuild against libtiff 3.7 without 2nd patch from http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=397 (simple correction for newer version number in configure) notes: * man.so patch now N/A - man pages listed in bug 35763 seem to have been removed * security patches look like they have been applied with some updates to 3.7 source * shared lib names patch from http://www.asmail.be/msg0054539720.html or http://xserve.flids.com/pipermail/tiff/2004-October/000620.html * lzw-tiff stuff now included in original tar (lzw patent expired although there is --disable-lzw conf option) * html docs aren't installed atm * tiffgt and tiffsv (tools/) require gl, want? * patch to tiff2ps correcting float->double conversion which causes the BoundingBox to be set incorrectly and hence the image to not fit the page properly
Created attachment 42253 [details] files/sharedlibsnamefix.patch
Created attachment 42254 [details] files/tiff2ps_float.patch
Now in CVS; new hylafax shortly.
Is there any concern on how this leaves the current unmasked hylafax ebuild? Also, I forgot to revert the unpack to unpack ${A} in the tiff ebuild There is a bugzilla entry for the lack of html docs installation here: http://bugzilla.remotesensing.org/show_bug.cgi?id=639 from the mailing thread http://www.asmail.be/msg0054570120.html
The unpack seems to work, and I just cleaned up the older hylafax ebuilds, leaving the latest stable 4.1.8-r4 (still needs testing on ~alpha ~amd64 ~ppc) and the new 4.2.0-r1, which needs testing on all arches.
What needs to be done to verify 4.2.0 as stable on x86? I've actually found it performs better thatn 4.1 in my case.
Wait the normal period (~30 days) for additional bug reports, if any. The new tiff and hylafax ebuilds were commited ~x86 on 23 Oct. Also, try to get feedback on other arches. This part is my job :) For now, you can add the new tiff/hylafax to /etc/portage/package.keywords. This is the recommended method (as opposed to ACCEPT_KEYWORDS or using the ebuild filename directly). I'm working on getting sparc going, but right now I can only test on x86. Anyone who uses (or can at least test) tiff and hylafax on the following arches please feel free: ~ppc ~sparc ~mips ~alpha ~arm ~hppa ~amd64 ~ia64 ~s390 ~macos ~ppc-macos ~ppc64 The real test requires actually faxing and using the libtiff stuff, hopefully both sending and receiving/decoding a fax (meaning I'm reluctant to bump without such a test).
