Re: libjpeg8: Please provide variant compiled with #define D_MAX_BLOCKS_IN_MCU 64
- To: 582522@bugs.debian.org
- Cc: ghostscript@packages.debian.org
- Subject: Re: libjpeg8: Please provide variant compiled with #define D_MAX_BLOCKS_IN_MCU 64
- From: Jonathan Nieder <jrnieder@gmail.com>
- Date: Fri, 23 Dec 2011 17:35:07 -0600
- Message-id: <[🔎] 20111223233507.GA25158@elie.Belkin>
- In-reply-to: <20110806232954.GA4850@elie.gateway.2wire.net>
- References: <20110218122114.GG7245@jones.dk> <20110218124852.GV22652@yellowpig> <20110218131937.GJ7245@jones.dk> <20110305230839.GD2362@yellowpig> <20110806232954.GA4850@elie.gateway.2wire.net>
reassign 582522 ghostscript 8.64~dfsg-2
quit
Jonathan Nieder wrote:
> Bill Allombert wrote:
>> Honestly, unless you provide evidence that PS files that include invalid
>> jpeg-encoded data are still in use, I am not going to include two new packages
>> to support non-standard compliant data in Debian, and in any case, I doubt the
>> FTP master would let me.
>
> Makes sense. Currently ghostscript/README.Debian says:
[...]
> http://www.ghostscript.com/pipermail/gs-code-review/2002-March/002275.html
> tells a slightly different story:
[...]
> So I do not even think that there are old Adobe interpreters involved
> (despite what jpeglib.h says). Would it be enough to say something
> like this?
[...]
> If you come across a file triggering either of these
> conditions, please let us know by reporting a bug against
> the ghostscript package.
Hence reassigning to ghostscript. I suggest updating the README.Debian
to clarify this, and perhaps contacting upstream to encourage them to
consider dropping the "#define D_MAX_BLOCKS_IN_MCU 64" hack, too.
Thanks for your help.
Jonathan
Reply to: