Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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 an attachment (id=42253) [details]
files/sharedlibsnamefix.patch

Created an attachment (id=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).