Debian Bug report logs - #602034
ITP: libjpeg-turbo -- an accelerated libjpeg library

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Laurent Bonnaud <Laurent.Bonnaud@inpg.fr>

To: Debian BTS submission <submit@bugs.debian.org>

Subject: libjpeg-turbo

Date: Sun, 31 Oct 2010 23:13:24 +0100

Package: libjpeg8
Severity: wishlist

Hi,

could you please provide libjpeg-turbo, which is much faster than
libjpeg ?

  http://libjpeg-turbo.virtualgl.org/
  http://sourceforge.net/projects/libjpeg-turbo/

It has recently replaced libjpeg in Fedora:

  http://fedoraproject.org/wiki/Features/libjpeg-turbo

-- 
Laurent Bonnaud <Laurent.Bonnaud@inpg.fr>

Message #10 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Adrien Clerc <adrien@antipoul.fr>

To: 602034@bugs.debian.org

Subject: Alternative to libjpeg62

Date: Thu, 04 Nov 2010 21:15:20 +0100

 Hi,

Be careful though that libjpeg-turbo is API and ABI compatible with 
libjpeg62. SVN trunk code is able to emulate some parts of the ABI / API 
in libjpeg8, but it is far from complete. Authors don't even know if the 
missing code will be added some day.
However, since Debian is still using libjpeg62 for a lot of packages 
(actually, only renrot is using libjpeg8), it can be a good idea to 
package it as a replacement of libjpeg62. I've tested it with geeqie, 
and it *is* much faster.

Adrien

Message #15 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: Adrien Clerc <adrien@antipoul.fr>, 602034@bugs.debian.org

Cc: 602034-submitter@bugs.debian.org

Subject: Re: Bug#602034: Alternative to libjpeg62

Date: Thu, 4 Nov 2010 21:26:09 +0100

On Thu, Nov 04, 2010 at 09:15:20PM +0100, Adrien Clerc wrote:
>  Hi,
> 
> Be careful though that libjpeg-turbo is API and ABI compatible with
> libjpeg62. SVN trunk code is able to emulate some parts of the ABI /
> API in libjpeg8, but it is far from complete. Authors don't even
> know if the missing code will be added some day.

Hello,

Last time I checked, libjpeg-turbo does not have versionned symbols so it is not possible to
use it in Debian.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #23 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Gürkan Sengün <gurkan@phys.ethz.ch>

To: 602034@bugs.debian.org

Subject: libjpeg-turbo

Date: Fri, 26 Nov 2010 09:40:26 +0100

hello Bill and Laurent

So nobody will try/work on this to have it packaged in debian? What about the 
current versions now?

yours,
gurkan

Message #28 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: Gürkan Sengün <gurkan@phys.ethz.ch>, 602034@bugs.debian.org

Cc: 602034-submitter@bugs.debian.org

Subject: Re: Bug#602034: libjpeg-turbo

Date: Fri, 26 Nov 2010 10:10:00 +0100

On Fri, Nov 26, 2010 at 09:40:26AM +0100, Gürkan Sengün wrote:
> hello Bill and Laurent
> 
> So nobody will try/work on this to have it packaged in debian? What
> about the current versions now?

Hello Gürkan,

The current version of libjpeg-turbo does not have versionned symbols, so it 
cannot be packaged.
I would prefer to wait until squeeze is released before taking any decision 
on libjpeg-turbo.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #36 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Albert Huang <ash@debian.org>

To: 602034@bugs.debian.org, 602034-submitter@bugs.debian.org

Subject: libjpeg-turbo

Date: Fri, 17 Dec 2010 12:10:42 -0500

Hi Bill,

I've taken an interest in libjpeg-turbo and would like to help out
with this.  Not sure if anything has happened in the last few weeks,
or if you've been concentrating on squeeze.  The version of libjpeg.so
in libjpeg-turbo 1.0.1 looks fine to me -- it has an identical SONAME
as the one provided in libjpeg62, and appears to be ABI compatible.
It also provides a libturbojpeg.so, which is isn't versioned properly,
is this what you're referring to?  In any case, the libjpeg.so could
co-exist in the repositories with libjpeg62 by using
/etc/alternatives, yes?

Regards,
Albert

Message #44 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: Albert Huang <ash@debian.org>, 602034@bugs.debian.org

Cc: 602034-submitter@bugs.debian.org, Gürkan Sengün <gurkan@phys.ethz.ch>, Adrien Clerc <adrien@antipoul.fr>

Subject: Re: Bug#602034: libjpeg-turboo

Date: Sat, 18 Dec 2010 18:48:06 +0100

On Fri, Dec 17, 2010 at 12:10:42PM -0500, Albert Huang wrote:
> Hi Bill,
> 
> I've taken an interest in libjpeg-turbo and would like to help out
> with this.  Not sure if anything has happened in the last few weeks,
> or if you've been concentrating on squeeze.  

Hello Albert,

I will not do anything before squeeze is released.

So far, my plan for squeeze+1 is to move to libjpeg8, so compatibility with libjpeg62
is irrelevant, since no packages will be build against libjpeg62 anymore. There is
going to be more and more jpeg files that will require libjpeg8 to be decoded properly
so staying with libjpeg62 is not an option.

> The version of libjpeg.so
> in libjpeg-turbo 1.0.1 looks fine to me -- it has an identical SONAME
> as the one provided in libjpeg62, and appears to be ABI compatible.

Yes, versioned symbols was added in 1.0.1 at my request. They were not there
when I first replied to this bug report.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #52 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Gürkan Sengün <gurkan@phys.ethz.ch>

To: 602034@bugs.debian.org

Subject: libjpeg-turbo

Date: Wed, 09 Feb 2011 09:21:14 +0100

Hello Bill

Thanks for your efforts. I wouldn't mind trying beta/alpha versions if you have
any somewhere?

Yours,
Gurkan

Message #57 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: 602034@bugs.debian.org, ballombe@debian.org

Cc: ash@debian.org, gurkan@phys.ethz.ch

Subject: libjpeg-turbo

Date: Fri, 4 Mar 2011 20:11:50 +0200

Hi,

whats the plan, now that freeze is gone?

fedora moved to libjpeg-turbo, is there some convincing reason
to go with abi-incompatible new libjpeg version instead?

Riku

Message #62 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: Riku Voipio <riku.voipio@iki.fi>, 602034@bugs.debian.org

Cc: ballombe@debian.org, ash@debian.org, gurkan@phys.ethz.ch

Subject: Re: Bug#602034: libjpeg-turbo

Date: Sat, 5 Mar 2011 15:30:40 +0100

On Fri, Mar 04, 2011 at 08:11:50PM +0200, Riku Voipio wrote:
> Hi,
> 
> whats the plan, now that freeze is gone?

My plan is to move to libjpeg8. libjpeg62 is a technological dead-end. 
libjpeg8 support a larger part of the JPEG standard than libjpeg62.
When images that make advantage of that start to be widespread, users
will need libjpeg8 support.

> fedora moved to libjpeg-turbo, is there some convincing reason
> to go with abi-incompatible new libjpeg version instead?

My understanding is that Fedora plan to move to the libjpeg8 ABI.
Gentoo and Mandriva already have.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #67 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

Cc: Riku Voipio <riku.voipio@iki.fi>, 602034@bugs.debian.org, ballombe@debian.org, ash@debian.org, gurkan@phys.ethz.ch

Subject: Re: Bug#602034: libjpeg-turbo

Date: Mon, 7 Mar 2011 14:19:39 +0200

On Sat, Mar 05, 2011 at 03:30:40PM +0100, Bill Allombert wrote:
> My plan is to move to libjpeg8. libjpeg62 is a technological dead-end. 
> libjpeg8 support a larger part of the JPEG standard than libjpeg62.
> When images that make advantage of that start to be widespread, users
> will need libjpeg8 support.

from what I have heard, libjpeg8 doesn't not support "larger part of JPEG
standard" but rather a "new proposal for Version 8.0" of JPEG specification:

http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/

personally, I feel really uncomfortable that out of blue new, incompatible
jpeg format has been introduced. Even if debian starts supporting these
features, there is huge amount of older installations and even hardware
that only supports the "old" jpeg features.

> > fedora moved to libjpeg-turbo, is there some convincing reason
> > to go with abi-incompatible new libjpeg version instead?
 
> My understanding is that Fedora plan to move to the libjpeg8 ABI.

Do you have some source for this understanding? All I know they still
use libjpeg-turbo for F15:

http://pkgs.fedoraproject.org/gitweb/?p=libjpeg-turbo.git

Message #72 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: Riku Voipio <riku.voipio@iki.fi>

Cc: 602034@bugs.debian.org, ballombe@debian.org, ash@debian.org, gurkan@phys.ethz.ch

Subject: Re: Bug#602034: libjpeg-turbo

Date: Mon, 7 Mar 2011 23:20:18 +0100

On Mon, Mar 07, 2011 at 02:19:39PM +0200, Riku Voipio wrote:
> On Sat, Mar 05, 2011 at 03:30:40PM +0100, Bill Allombert wrote:
> > My plan is to move to libjpeg8. libjpeg62 is a technological dead-end. 
> > libjpeg8 support a larger part of the JPEG standard than libjpeg62.
> > When images that make advantage of that start to be widespread, users
> > will need libjpeg8 support.
> 
> from what I have heard, libjpeg8 doesn't not support "larger part of JPEG
> standard" but rather a "new proposal for Version 8.0" of JPEG specification:
> 
> http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/

This article miss the point entirely by assuming that "JPEG is only used for
the final published version" and does not mention other changes that lead to
support larger part of the JPEG standard. It also totally ignore image quality 
improvement.

> personally, I feel really uncomfortable that out of blue new, incompatible
> jpeg format has been introduced. Even if debian starts supporting these
> features, there is huge amount of older installations and even hardware
> that only supports the "old" jpeg features.

Debian not supporting theses features is not a better option.

> > > fedora moved to libjpeg-turbo, is there some convincing reason
> > > to go with abi-incompatible new libjpeg version instead?
>  
> > My understanding is that Fedora plan to move to the libjpeg8 ABI.
> 
> Do you have some source for this understanding? All I know they still
> use libjpeg-turbo for F15:
> 
> http://pkgs.fedoraproject.org/gitweb/?p=libjpeg-turbo.git

My understanding is that RedHat sponsored support of libjpeg8 ABI to libjpeg-turbo,
so they probably plan to use it.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #77 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: 602034@bugs.debian.org, ballombe@debian.org, ash@debian.org, gurkan@phys.ethz.ch

Subject: Re: Bug#602034: libjpeg-turbo

Date: Thu, 29 Sep 2011 10:18:21 +0300

Hi,

libjpeg-turbo packages now in ubuntu:

https://launchpad.net/ubuntu/+source/libjpeg-turbo/

There is also a new ITP at #612341 

Message #96 received at 602034@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

To: Riku Voipio <riku.voipio@iki.fi>

Cc: 602034@bugs.debian.org, ballombe@debian.org, ash@debian.org, gurkan@phys.ethz.ch

Subject: Re: Bug#602034: libjpeg-turbo

Date: Thu, 8 Nov 2012 12:23:11 +0100

[Message part 1 (text/plain, inline)]

Hi,

just a short heads-up to motivate the packaging of libjpeg-turbo.

The Steam for Linux package [1] has a dependency on libjpeg8-turbo,
hence the unavailability of libjpeg-turbo currently means Debian users
cannot install Steam (besides the fact that libc6 is too old, too).

Cheers,

Adrian

> [1] http://media.steampowered.com/client/installer/steam.deb

[signature.asc (application/pgp-signature, inline)]

Message #101 received at 602034@bugs.debian.org (full text, mbox, reply):

From: DRC <dcommander@users.sourceforge.net>

To: 602034@bugs.debian.org

Date: Fri, 08 Feb 2013 16:28:55 -0600

Just FYI-- Fedora has scrapped its plans to update to the libjpeg v8 
ABI, and further research 
(http://www.libjpeg-turbo.org/About/SmartScale) has raised 
questions/concerns regarding whether the features introduced in libjpeg 
v7 and later really solve any problems that couldn't already be solved 
via other means.  Until or unless SmartScale is adopted as an official 
standard or more compelling research comes to light regarding its 
usefulness as a format, it is our (The libjpeg-turbo Project's) position 
that supporting it will do more harm than good.  To quote Tom Lane 
(http://lists.fedoraproject.org/pipermail/devel/2013-January/176400.html), 
"If there were a huge improvement in compression performance maybe 
there'd be some chance of establishing a new de facto standard, but 
there isn't --- so this will accomplish little except to fragment the 
market."

The less controversial features of libjpeg v8 -- arithmetic coding 
(which is part of the official JPEG spec, even though it isn't widely 
used), the in-memory source/destination managers, support for additional 
decompression scaling factors, etc. have all been back-ported as 
extensions to libjpeg-turbo's API, thus allowing libjpeg-turbo to 
support those features of libjpeg v8 without breaking backward ABI 
compatibility for applications that don't use the features.  It is safe 
to assume that, for the forseeable future, the emulated libjpeg v8 API 
in libjpeg-turbo will remain feature-incomplete and will not actually 
support any features that can't also be accessed through our libjpeg 
v6b-compatible API.  Thus, the only compelling reason to use libjpeg v8 
emulation in libjpeg-turbo is in situations where the platform or 
application has already upgraded to libjpeg v8 and maintaining ABI 
compatibility with previous releases of the application/platform is desired.

If there are any applications that actually use the SmartScale or 
forward DCT scaling features, I would be very interested to hear about 
them.  We (myself and Fedora) have not been able to identify any at this 
time.

I also need to clarify that Red Hat did not pay for the libjpeg v7 and 
v8 API/ABI emulation feature.  It was paid for by CamTrace 
(http://www.libjpeg-turbo.org/About/Sponsors).

Message #108 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Federico Bruni <fedelogy@gmail.com>

To: 602034@bugs.debian.org

Date: Sun, 17 Mar 2013 09:47:15 +0100

Hi

just to let you know that .deb packages are available from:
http://sourceforge.net/projects/libjpeg-turbo/files/

I've just installed it in order to compile kradradio:
http://kradradio.com/

Regards
-- 
Federico

Message #115 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@sury.org>

To: Bill Allombert <ballombe@debian.org>, 602034@bugs.debian.org, debian-devel@lists.debian.org

Subject: jpeg8 vs jpeg-turbo

Date: Wed, 24 Apr 2013 11:23:04 +0200

Hi Bill and Debian Developers,

while doing work on GD Library 2.1.0 it was discovered there's
encoding incompatibility introduced by libjpeg8/9 [1]. While doing
further research I have found that Fedora has switched to
libjpeg-turbo[2] (for reasoning please read the referred email).
Ubuntu (and Steam) is also using libjpeg-turbo as base jpeg library.
SuSE has also switched to libjpeg-turbo some time ago (just had a
quick chat with it's maintainer).

Debian has already open ITP[3] #602034 for libjpeg-turbo, which
support libjpeg62 API/ABI and also some important bits of libjpeg8. As
libjpeg is one of the base libraries of the system, I think it might
be a good idea to discuss this project wide. Also although I have an
opinion (as you might have guessed from this email) that we should try
to be aligned with other distributions and the reasoning for not going
for , I will be happy with whatever result will end-up.

My proposal is:
A. Add libjpeg-turbo to Debian archive (that's easy)
B. Add required provides/alternatives for libjpeg62-dev and
libjpeg8-dev (where API/ABI match)
C. Decide which package should provide default libjpeg-dev library

1. https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034

Ondrej
--
Ondřej Surý <ondrej@sury.org>

Message #120 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Ondřej Surý <ondrej@sury.org>, 602034@bugs.debian.org

Cc: Bill Allombert <ballombe@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#602034: jpeg8 vs jpeg-turbo

Date: Wed, 24 Apr 2013 13:48:48 +0200

[Message part 1 (text/plain, inline)]

Hi Ondřej,

I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW [1].

On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote:

> Debian has already open ITP[3] #602034 for libjpeg-turbo, which
> support libjpeg62 API/ABI and also some important bits of libjpeg8. As
> libjpeg is one of the base libraries of the system, I think it might
> be a good idea to discuss this project wide. Also although I have an
> opinion (as you might have guessed from this email) that we should try
> to be aligned with other distributions and the reasoning for not going
> for , I will be happy with whatever result will end-up.

In an IRC discussion in #debian-devel several weeks ago the consensus  
was: the RT team (represented Julien) will probably not want two  
libjpeg implementations in Debian. My first packaging approach aimed  
at having the compat mode libraries available [2] and allow the user  
to install them as a drop-in replacement for libjpeg8.

The IRC discussion lead to the result that the compat packages are not  
wanted in Debian, only the native TURBOjpeg ABI. I was asked to ping  
Bill Allombert about his opinion to transition from libjpeg8 fully to  
libjpeg8-turbo. @Bill: can you repeat your disposition here again? I  
guess our earlier mailing was a private mail exchange.

> A. Add libjpeg-turbo to Debian archive (that's easy)

Done. Waiting in NEW. Only containing libturbojpeg.so.1

> B. Add required provides/alternatives for libjpeg62-dev and
> libjpeg8-dev (where API/ABI match)

A packaging example can be seen in [1]. If the packages disappears  
from the NEW queue, you can also obtain a libjpeg-turbo version with  
compat packages provided here [3].

> C. Decide which package should provide default libjpeg-dev library

Last statement from Bill: libjpeg by IJG

Greets,
Mike


[1] http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-2.html
[2] http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-1.html
[3] http://packages.x2go.org/debian/pool/main/libj/libjpeg-turbo/

-- 

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #125 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>

To: Ondřej Surý <ondrej@sury.org>

Cc: Bill Allombert <ballombe@debian.org>, 602034@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: jpeg8 vs jpeg-turbo

Date: Wed, 24 Apr 2013 15:19:59 +0200

On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> Hi Bill and Debian Developers,
> 
> My proposal is:
> A. Add libjpeg-turbo to Debian archive (that's easy)
> B. Add required provides/alternatives for libjpeg62-dev and
> libjpeg8-dev (where API/ABI match)
> C. Decide which package should provide default libjpeg-dev library
> 
> 1. https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
> 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
> 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034

As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature.

I do not see libjpeg-turbo as a suitable replacement. It has
1) an different license.
2) much more security issues in a much smaller timeframe.
3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Message #130 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

Cc: Ondřej Surý <ondrej@sury.org>, 602034@bugs.debian.org, Bill Allombert <ballombe@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#602034: jpeg8 vs jpeg-turbo

Date: Wed, 24 Apr 2013 17:01:50 +0300

On Wed, Apr 24, 2013 at 01:48:48PM +0200, Mike Gabriel wrote:
> >C. Decide which package should provide default libjpeg-dev library
 
> Last statement from Bill: libjpeg by IJG

The current IJG has nothing to do with the IJG that originally created JPEG. 
The last activity of original IJG was in 1998, while new IJG surfaced in 2009.
Thus we actually have two forks:

1) the "new IJG" libjpeg, which changes API/ABI of the original libjpeg
library, and adds new features to JPEG image format. However the new
image format features have been rejected as not improving image quality
or compression ratio[1].

The "new IJG" has no mailing list, VCS or any or other sign of actually
being group - all apparent IJG work seems to come from a single person.
The website of IJG[2] is void of details - who is in IJG? - how does
it make decisions like changing the JPEG image format to add "SmartScale
support? There is even no place to send bug reports! 

2) libjpeg-turbo remains API/ABI and binary format compatible with original
libjpeg. The most significant improvements are in supporting SIMD
features to make JPEG image encoding and decoding faster on modern
cpu's.

Libjpeg-turbo website [3] has all the signs of an healthy open source
project - A SVN repo with many commiters, bug tracker, a mailing list
with open discussion etc.

So the Debian options is to choose a libjpeg fork that changes the jpeg image
format, or one that renders images fast. At the moment the first
fork is being advertized with IJG name, thus painting an image of
"official upstream". But it isn't - especially not now when the changes
libjpeg8 added to JPEG standard have been rejected from the ISO standard.

Riku

[1] http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/
[2] http://www.ijg.org/
[3] http://www.libjpeg-turbo.org/

Message #135 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Aron Xu <happyaron.xu@gmail.com>

To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Ondřej Surý <ondrej@sury.org>, Bill Allombert <ballombe@debian.org>, 602034@bugs.debian.org, debian developers <debian-devel@lists.debian.org>

Subject: Re: jpeg8 vs jpeg-turbo

Date: Wed, 24 Apr 2013 22:10:42 +0800

On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert
<Bill.Allombert@math.u-bordeaux1.fr> wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>> Hi Bill and Debian Developers,
>>
>> My proposal is:
>> A. Add libjpeg-turbo to Debian archive (that's easy)
>> B. Add required provides/alternatives for libjpeg62-dev and
>> libjpeg8-dev (where API/ABI match)
>> C. Decide which package should provide default libjpeg-dev library
>>
>> 1. https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
>> 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
>> 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034
>
> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature.
>

From a user's prospective, I don't think adding bunches of not widely
used features is that useful (I mean it's useful but not that
important), but speed does matter a lot, especially on slower hardware
like ARM-boards.



--
Regards,
Aron Xu

Message #140 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Riku Voipio <riku.voipio@iki.fi>

Cc: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>, Ondřej Surý <ondrej@sury.org>, 602034@bugs.debian.org, Bill Allombert <ballombe@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#602034: jpeg8 vs jpeg-turbo

Date: Wed, 24 Apr 2013 16:26:44 +0200

On Wed, Apr 24, 2013 at 05:01:50PM +0300, Riku Voipio wrote:
> Libjpeg-turbo website [3] has all the signs of an healthy open source
> project - A SVN repo with many commiters, bug tracker, a mailing list
> with open discussion etc.

libjpeg-turbo is also used by webkit, blink, and gecko.

Mike

Message #145 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Riku Voipio <riku.voipio@iki.fi>

To: Ondřej Surý <ondrej@sury.org>, Bill Allombert <ballombe@debian.org>, 602034@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: jpeg8 vs jpeg-turbo

Date: Thu, 25 Apr 2013 07:17:40 +0300

On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature.

Only the applications that actually want to experiment with libjpeg8/9 ABI should be using it -

The 100% of current applications that work just libjpeg-turbo should be
using libjpeg-turbo for better performance and compatibility with rest
of the linux distributions.

Which feature in libjpeg9 does anyone want? The ability to make jpeg's
images that nobody else can view?

> I do not see libjpeg-turbo as a suitable replacement. It has
> 1) an different license

Be specific, what do you not like about libjpeg-turbo license? As far as
I see, it is under the exact same license?

> 2) much more security issues in a much smaller timeframe.

Which translates to.. a single CVE in libjpeg-turbo since it's
inception!

> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.

This would be a relevant if some application actually used the
"full libjpeg8 ABI" . In fact, 100% of debian works fine with
libjpeg-turbo, or even the original libjpeg6b (if the would be
recompiled against it again). 

I find the reason that IJG libjpeg8 fork is so triggerhappy to
repeatedly break the API and ABI (and image format!) rather a reason 
to make libjpeg8 the non-default. 

You should not deprive debian users from high performance jpeg rendering
for a few ABI features that nobody uses - or anyone is asking for.

Riku

Message #150 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Mathieu Malaterre <malat@debian.org>

To: Riku Voipio <riku.voipio@iki.fi>

Cc: 602034@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: jpeg8 vs jpeg-turbo

Date: Thu, 25 Apr 2013 09:18:25 +0200

On Thu, Apr 25, 2013 at 6:17 AM, Riku Voipio <riku.voipio@iki.fi> wrote:
> On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
>> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature.
>
> Only the applications that actually want to experiment with libjpeg8/9 ABI should be using it -
>
> The 100% of current applications that work just libjpeg-turbo should be
> using libjpeg-turbo for better performance and compatibility with rest
> of the linux distributions.
>
> Which feature in libjpeg9 does anyone want? The ability to make jpeg's
> images that nobody else can view?

Chicken & egg issue, until everyone follow debian and uses libjpeg9,
there may be surprise.

>> I do not see libjpeg-turbo as a suitable replacement. It has
>> 1) an different license
>
> Be specific, what do you not like about libjpeg-turbo license? As far as
> I see, it is under the exact same license?
>
>> 2) much more security issues in a much smaller timeframe.
>
> Which translates to.. a single CVE in libjpeg-turbo since it's
> inception!
>
>> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.
>
> This would be a relevant if some application actually used the
> "full libjpeg8 ABI" . In fact, 100% of debian works fine with
> libjpeg-turbo, or even the original libjpeg6b (if the would be
> recompiled against it again).
>
> I find the reason that IJG libjpeg8 fork is so triggerhappy to
> repeatedly break the API and ABI (and image format!) rather a reason
> to make libjpeg8 the non-default.
>
> You should not deprive debian users from high performance jpeg rendering
> for a few ABI features that nobody uses - or anyone is asking for.

I do not believe in debian life-span, a package manager ever switch an
implementation of a package. So libjpeg9 and libjpeg-turbo will have
to co-live.

I understand your point that libjpeg9 offers experimental feature not
needed for everyone, but at least from my point of view libjpeg-turbo
by only implementing portion of ITU-T T.81, ISO/IEC IS 10918-1 (namely
lossy 8bits progressive & sequential) is a no-go for my applications.
Have a look at ITK, DCMTK and/or GDCM which provide a patched libjpeg
to provide support for lossy 8 & 12 bits and lossless 16bits. This is
a burden to maintain those side implementations.

This goes without saying that JPEG commitee is now working on a full
implementation of ITU 81:

https://github.com/thorfdbg/libjpeg

Which also has a different license, may be slower, but *at last*
provide a complete implementation of JPEG. It is said to provide an
ABI compatible with the original IJG implementation in the near
future. So debian may have to provide three JPEG implementations

This bug will be really messy to read, but I wished the team from
libjpeg-turbo and whoever is running IJG found a compromise to either
integrate optimization from -turbo into jpeg9, or the other way
around, -turbo provides empty body function for the new API. oh
well...

-M

Message #155 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Peter Samuelson <peter@p12n.org>

To: Mathieu Malaterre <malat@debian.org>

Cc: Riku Voipio <riku.voipio@iki.fi>, 602034@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: jpeg8 vs jpeg-turbo

Date: Thu, 25 Apr 2013 10:28:59 -0500

[Mathieu Malaterre]
> I do not believe in debian life-span, a package manager ever switch
> an implementation of a package. So libjpeg9 and libjpeg-turbo will
> have to co-live.

It happens.  Look at the source for 'libc6'.  It used to be glibc,
these days it is a fork called eglibc.  Likewise the source for the
'ssh' package was once SSH by Tatu Ylonen, these days it is a fork
called OpenSSH maintained by some OpenBSD hackers.

Message #160 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Ondřej Surý <ondrej@sury.org>

To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Ondřej Surý <ondrej@sury.org>, Bill Allombert <ballombe@debian.org>, 602034@bugs.debian.org, debian-devel@lists.debian.org

Subject: Re: jpeg8 vs jpeg-turbo

Date: Thu, 25 Apr 2013 18:41:40 +0200

On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
<Bill.Allombert@math.u-bordeaux1.fr> wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>> Hi Bill and Debian Developers,
>>
>> My proposal is:
>> A. Add libjpeg-turbo to Debian archive (that's easy)
>> B. Add required provides/alternatives for libjpeg62-dev and
>> libjpeg8-dev (where API/ABI match)
>> C. Decide which package should provide default libjpeg-dev library
>>
>> 1. https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
>> 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
>> 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034
>
> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more feature.
>
> I do not see libjpeg-turbo as a suitable replacement. It has
> 1) an different license.
> 2) much more security issues in a much smaller timeframe.
> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.

Bill,

sorry to barge in, but as a maintainer of the most prominent rev-deps
of libjpeg (libgd2 & php5-gd), I would like to have some questions
answered, and I cannot find the answer neither on http://www.ijg.org/
nor http://www.infai.org/jpeg/.

1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
2. What's the legal status of IJG?
3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
4. Is there a (public) bug tracker?
5. Is there a source repository?
6. Is there a mailing list for libjpeg development/users?
7. How do I contribute code to IJG libjpeg?
8. There are new features incorporated to libjpeg? Is that a community
process? Or how are the changes driven? IJG (and the features they
implement in libjpeg) is independent from jpeg.org (the standards
committee).
9. Is there a documentation for new features of libjpeg (DCT,
SmartScale), so independent implementations can be done?
10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
comment rant under: http://blog.kaourantin.net/?p=116)

I haven't been able to find answers at IJG or any linked sites, so as
you are so far the only one taking stand for IJG jpeg implementation,
I would like to to help me to answer those questions.

I wouldn't bother to care about libjpeg in Debian, but it's one of the
core graphics libraries, and I think we should strive for good
compatibility with the rest of the distros, applications and our
users. And the 'new features' of libjpeg seems to contradict this.

Ondrej
--
Ondřej Surý <ondrej@sury.org>

Message #165 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Ondřej Surý <ondrej@sury.org>, 602034@bugs.debian.org

Cc: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, Ondřej Surý <ondrej@sury.org>, Bill Allombert <ballombe@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#602034: jpeg8 vs jpeg-turbo

Date: Thu, 25 Apr 2013 20:49:26 +0200

[Message part 1 (text/plain, inline)]

Hi all,

On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote:

> On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
> <Bill.Allombert@math.u-bordeaux1.fr> wrote:
>> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>>> Hi Bill and Debian Developers,
>>>
>>> My proposal is:
>>> A. Add libjpeg-turbo to Debian archive (that's easy)
>>> B. Add required provides/alternatives for libjpeg62-dev and
>>> libjpeg8-dev (where API/ABI match)
>>> C. Decide which package should provide default libjpeg-dev library
>>>
>>> 1.  
>>> https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
>>> 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
>>> 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034
>>
>> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has  
>> more feature.
>>
>> I do not see libjpeg-turbo as a suitable replacement. It has
>> 1) an different license.
>> 2) much more security issues in a much smaller timeframe.
>> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.
>
> Bill,
>
> sorry to barge in, but as a maintainer of the most prominent rev-deps
> of libjpeg (libgd2 & php5-gd), I would like to have some questions
> answered, and I cannot find the answer neither on http://www.ijg.org/
> nor http://www.infai.org/jpeg/.
>
> 1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
> 2. What's the legal status of IJG?
> 3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
> 4. Is there a (public) bug tracker?
> 5. Is there a source repository?
> 6. Is there a mailing list for libjpeg development/users?
> 7. How do I contribute code to IJG libjpeg?
> 8. There are new features incorporated to libjpeg? Is that a community
> process? Or how are the changes driven? IJG (and the features they
> implement in libjpeg) is independent from jpeg.org (the standards
> committee).
> 9. Is there a documentation for new features of libjpeg (DCT,
> SmartScale), so independent implementations can be done?
> 10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
> comment rant under: http://blog.kaourantin.net/?p=116)

All questions are really good questions. Some of them have already  
been answered in the backlogs of #602034 [1] and the-merged-with bug  
#612341 [2].

Reading through both of them is probably a good idea for all who are  
interested in the complete story.

Esp. some statements from Guido Vollbeding [3] make me ask myself:  
hey, what kind of guy is that and what is the stand of the IJG in the  
free software ecosystem. His arguing tends to be somehow aggressive  
and inbalanced. One quote that shows what I mean (taken from [3]):

"""
It seems that Bill Allombert is still one of the few sane people out
there, many others have apparently gone mad.
I don't care for the ignorant people.
"""

@Bill: Unfortunately, I am not an expert with image processing, but  
most of what I have read in this thread speaks for re-thinking the  
current strategy of staying with libjpeg IJG.

Can this be a proposal? Package libjpeg and libjpeg-turbo using an  
alternatives setup and thus, making both libs installable in parallel.  
Packagers can then build-depend on one or the other libjpeg  
implementations.

Greets,
Mike

[1] http://bugs.debian.org/602034
[2] http://bugs.debian.org/612341
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612341#116


-- 

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #170 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Pau Garcia i Quiles <pgquiles@elpauer.org>

To: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

Cc: Ondřej Surý <ondrej@sury.org>, 602034@bugs.debian.org, Bill Allombert <ballombe@debian.org>, debian-devel@lists.debian.org

Subject: Re: Bug#602034: jpeg8 vs jpeg-turbo

Date: Thu, 25 Apr 2013 21:39:47 +0200

[Message part 1 (text/plain, inline)]

Hello,

The KDE maintainer in Fedora started an interesting discussion some time
ago in Digikam's mailing list. There was input from the very IJG:

http://mail.kde.org/pipermail/digikam-devel/2013-January/066206.html

It boils down to "jpeg6-2 is the only important thing. Forget about jpeg8
and jpeg9, which bring incompatible changes".

http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html

FWIW, Arch and Gentoo also follow the policy that jpeg6-2 (and jpeg-turbo
with 6-2 API/ABI) is the real deal.



On Wed, Apr 24, 2013 at 1:48 PM, Mike Gabriel <
mike.gabriel@das-netzwerkteam.de> wrote:

> Hi Ondřej,
>
> I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW
> [1].
>
> On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote:
>
>  Debian has already open ITP[3] #602034 for libjpeg-turbo, which
>> support libjpeg62 API/ABI and also some important bits of libjpeg8. As
>> libjpeg is one of the base libraries of the system, I think it might
>> be a good idea to discuss this project wide. Also although I have an
>> opinion (as you might have guessed from this email) that we should try
>> to be aligned with other distributions and the reasoning for not going
>> for , I will be happy with whatever result will end-up.
>>
>
> In an IRC discussion in #debian-devel several weeks ago the consensus was:
> the RT team (represented Julien) will probably not want two libjpeg
> implementations in Debian. My first packaging approach aimed at having the
> compat mode libraries available [2] and allow the user to install them as a
> drop-in replacement for libjpeg8.
>
> The IRC discussion lead to the result that the compat packages are not
> wanted in Debian, only the native TURBOjpeg ABI. I was asked to ping Bill
> Allombert about his opinion to transition from libjpeg8 fully to
> libjpeg8-turbo. @Bill: can you repeat your disposition here again? I guess
> our earlier mailing was a private mail exchange.
>
>  A. Add libjpeg-turbo to Debian archive (that's easy)
>>
>
> Done. Waiting in NEW. Only containing libturbojpeg.so.1
>
>  B. Add required provides/alternatives for libjpeg62-dev and
>> libjpeg8-dev (where API/ABI match)
>>
>
> A packaging example can be seen in [1]. If the packages disappears from
> the NEW queue, you can also obtain a libjpeg-turbo version with compat
> packages provided here [3].
>
>  C. Decide which package should provide default libjpeg-dev library
>>
>
> Last statement from Bill: libjpeg by IJG
>
> Greets,
> Mike
>
>
> [1] http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-2.**html<http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-2.html>
> [2] http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-1.**html<http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-1.html>
> [3] http://packages.x2go.org/**debian/pool/main/libj/libjpeg-**turbo/<http://packages.x2go.org/debian/pool/main/libj/libjpeg-turbo/>
>
> --
>
> DAS-NETZWERKTEAM
> mike gabriel, rothenstein 5, 24214 neudorf-bornstein
> fon: +49 (1520) 1976 148
>
> GnuPG Key ID 0x25771B31
> mail: mike.gabriel@das-netzwerkteam.**de<mike.gabriel@das-netzwerkteam.de>,
> http://das-netzwerkteam.de
>
> freeBusy:
> https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-**
> netzwerkteam.de.xfb<https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb>




-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

[Message part 2 (text/html, inline)]

Message #175 received at 602034@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: Ondřej Surý <ondrej@sury.org>

Cc: 602034@bugs.debian.org, debian-devel@lists.debian.org, pkg-phototools-devel@lists.alioth.debian.org

Subject: Re: jpeg8 vs jpeg-turbo

Date: Sat, 04 May 2013 06:11:48 +0200

Am 24.04.2013 11:23, schrieb Ondřej Surý:

do you have some insight how openjpeg enters this game? apparently some packages
already use openjpeg explicitly to support some jpeg2000 features. There was
some discussion on that in Ubuntu, see https://launchpad.net/bugs/711061.

  Matthias

Message #178 received at 612341-close@bugs.debian.org (full text, mbox, reply):

From: Mike Gabriel <sunweaver@debian.org>

To: 612341-close@bugs.debian.org

Subject: Bug#612341: fixed in libjpeg-turbo 1.2.90-1

Date: Fri, 31 May 2013 10:02:25 +0000

Source: libjpeg-turbo
Source-Version: 1.2.90-1

We believe that the bug you reported is fixed in the latest version of
libjpeg-turbo, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 612341@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mike Gabriel <sunweaver@debian.org> (supplier of updated libjpeg-turbo package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 24 Mar 2013 10:50:07 +0100
Source: libjpeg-turbo
Binary: libturbojpeg1 libturbojpeg1-dev libjpeg8-turbo libjpeg8-turbo-dev libjpeg8-turbo-dbg libjpeg-turbo-progs libjpeg-turbo-test
Architecture: source amd64
Version: 1.2.90-1
Distribution: sid
Urgency: low
Maintainer: Debian TigerVNC Packaging Team <pkg-tigervnc-devel@lists.alioth.debian.org>
Changed-By: Mike Gabriel <sunweaver@debian.org>
Description: 
 libjpeg-turbo-progs - Programs for manipulating JPEG files
 libjpeg-turbo-test - Program for testing libjpeg-turbo
 libjpeg8-turbo - IJG JPEG compliant runtime library - SIMD optimized
 libjpeg8-turbo-dbg - Debugging symbols for the libjpeg8-turbo library
 libjpeg8-turbo-dev - Development files for the IJG JPEG library
 libturbojpeg1 - TurboJPEG runtime library - SIMD optimized
 libturbojpeg1-dev - Development files for the turbo JPEG library
Closes: 612341
Changes: 
 libjpeg-turbo (1.2.90-1) unstable; urgency=low
 .
   [ Osamu Aoki ]
   * New upstream version. Closes: #612341
   * Merge package based on Ubuntu and Fathi Boudra.
 .
   [ Mike Gabriel ]
   * /debian/control:
     + Set maintainer to: Debian TigerVNC Packaging Team
       <pkg-tigervnc-devel@lists.alioth.debian.org>.
     + Raise Standards: version to 3.9.4 (after several changes, as described
       below).
     + Build-depend on debhelper (>= 9).
     + Fully re-arrange the bin:package naming scheme.
     + Hard-coded unversioned dependecy on libc6 for libjpeg-turbo-progs.
     + Hard-coded versioned dependency on libjpeg8-turbo for libjpeg-turbo-progs.
   * /debian/copyright:
     + License change for packaging files: BSD-3. Agreed upon by all copyright
       holders (see backlog of #612341).
     + Add TigerVNC Packaging Team to copyright holders of /debian/*.
     + Mention files in debian/extras/* separately in license file.
   * /debian/rules:
     + Change over to building libjpeg8-turbo (as opposed to libjpeg-turbo62
       in early versions of this src:package).
     + Enable unit tests during package build. Clean up test images during
       dh_auto_clean.
     + Provide a symlink (libjpeg.so.8.99.0) with libjpeg8-turbo that reliably
       (almost) always supersedes any IJG libjpeg.so.8.x.y version. This will
       trick SO_NAME symlinking of ldconfig in case the version of our
       libjpeg.so.8.x.y is lower than the version number of IJG's
       libjpeg.so.8.x.y (in the native libjpeg8 package).
     + Harden build of jpegexiforient in /debian/extra/.
   * /debian/patches:
     + Add patch: 001_versioned-libjpegturbo.patch. Adds versioned .so file
       support for libturbojpeg.so.
     + Add patch: 002_test-progs.patch. Install test programmes to debian/tmp/*.
   * Lintian overrides:
     + Add override for: libjpeg8-turbo: shlib-calls-exit
       usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2. Can be ignored as explained by
       upstream.
     + Add override for: libturbojpeg1: shlib-calls-exit
       usr/lib/x86_64-linux-gnu/libturbojpeg.so.1.2.90. Can be ignored as
       explained by upstream.
     + Add override for: libjpeg-turbo-test: binary-without-manpage
       usr/bin/tjunittest. No man page provided by upstream and only useful
       for package maintainers.
     + Add override for: libjpeg-turbo source: package-depends-on-hardcoded-libc
       libjpeg-turbo-progs depends. The generation of shlibs dependencies fail
       for bin:package libjpeg-turbo-progs. The result would be a versioned
       dependency on libjpeg8 (>= 8d) which is inappropriate for the
       libjpeg-turbo-progs package. The libjpeg-turbo-progs bin:package should be
       used with bin:package libjpeg8-turbo instead.
   * Dpkg diversions:
     + Rework all dpkg diversions, do not divert into subfolders anymore
     + Use dpkg-divert for libjpeg8-turbo-dev, as well (was: Conflicts:/Replaces:
       before).
Checksums-Sha1: 
 c6055faf32fc6fe11fc40272e00df04876d2f6ff 2452 libjpeg-turbo_1.2.90-1.dsc
 62dde4af23a5e55200eafd5ca521105e291f1508 1348523 libjpeg-turbo_1.2.90.orig.tar.gz
 0f1b235115d2774677153a570dbcc7f610af5ef0 16537 libjpeg-turbo_1.2.90-1.debian.tar.gz
 ce1804beb543250a590f7e4683a9ff53296ae884 227490 libturbojpeg1_1.2.90-1_amd64.deb
 fdb23eaed661e3591334f7614b26bee817ad3b37 179958 libturbojpeg1-dev_1.2.90-1_amd64.deb
 de02728f799fc003dd870415aadc75e83d99ffd7 132250 libjpeg8-turbo_1.2.90-1_amd64.deb
 dac473794ff8149b0c92836f09d13f94a18acffd 177854 libjpeg8-turbo-dev_1.2.90-1_amd64.deb
 2d86d0e8813c4064b4a8ce0fcdea13ea32cf551c 329054 libjpeg8-turbo-dbg_1.2.90-1_amd64.deb
 e2c1e6cf2d0bef34fcb2d50b29a8cb3929058f34 77674 libjpeg-turbo-progs_1.2.90-1_amd64.deb
 a85d9e536ae25206c0dac6814e0e5cadaa64965b 23120 libjpeg-turbo-test_1.2.90-1_amd64.deb
Checksums-Sha256: 
 22f551440cbd6e2a0831ba2d02e8280760493c3739cba67c7ab93862bb96632a 2452 libjpeg-turbo_1.2.90-1.dsc
 e42f3bdacaced1cbc3313ea33e0ec1f6e7247b9a15ca8faa532803f0b55756da 1348523 libjpeg-turbo_1.2.90.orig.tar.gz
 7b6217e51430ea9471308c32c94cc24604fadddfb0f08c88fc5ae2736f36ea6e 16537 libjpeg-turbo_1.2.90-1.debian.tar.gz
 75195e34bf8a5cd78eccb453db6f18fa20eb2a28faa31f8d2494ab77292f626f 227490 libturbojpeg1_1.2.90-1_amd64.deb
 0dd1b262f0188caf5bd1e0e46b2daec742d932919988ef9b9f6f4aff558174a7 179958 libturbojpeg1-dev_1.2.90-1_amd64.deb
 37b896366e68e7ecc3416735e6bc99cede420250f0229c38acd157cdb7da9ff3 132250 libjpeg8-turbo_1.2.90-1_amd64.deb
 2d475c57d2edad71b7bbc853756bd0de543e28b609e1404b39b11e58ad7c5ca1 177854 libjpeg8-turbo-dev_1.2.90-1_amd64.deb
 b265dac54f19d28792bc7fd25f226e64bb1ed9e0a11016aeb98aaf90a2aad59c 329054 libjpeg8-turbo-dbg_1.2.90-1_amd64.deb
 5c31b753a2833421514c8e63a13a50080a81de2bd285082209049597d1bbdf8c 77674 libjpeg-turbo-progs_1.2.90-1_amd64.deb
 1ea1a9e847366a6322da6d2c460bcee628a7440b5c08bdb20bf671fc0ffa6385 23120 libjpeg-turbo-test_1.2.90-1_amd64.deb
Files: 
 68cc3c5c7473a7ee56c57b8868221614 2452 graphics optional libjpeg-turbo_1.2.90-1.dsc
 ea53fc1e8a00c26e2f501385f887f1f6 1348523 graphics optional libjpeg-turbo_1.2.90.orig.tar.gz
 a2d70f2f720fc9d02d41bce11f9da610 16537 graphics optional libjpeg-turbo_1.2.90-1.debian.tar.gz
 1f390269a7a17135d7c73b1567c6edc1 227490 libs optional libturbojpeg1_1.2.90-1_amd64.deb
 e2b09f7657a9d756a7cf3496b4680086 179958 libdevel optional libturbojpeg1-dev_1.2.90-1_amd64.deb
 bab542eaa0a874ab4f73217e008d8d40 132250 libs optional libjpeg8-turbo_1.2.90-1_amd64.deb
 7d92e98edb90dee9695f4f58ec47bcf6 177854 libdevel optional libjpeg8-turbo-dev_1.2.90-1_amd64.deb
 2c5248bad0d3090b0fd7146d91e36291 329054 debug extra libjpeg8-turbo-dbg_1.2.90-1_amd64.deb
 84983a4608d84cb22425f1673992c4b7 77674 graphics optional libjpeg-turbo-progs_1.2.90-1_amd64.deb
 f889903bc5096dcbe3095a393aee844e 23120 debug extra libjpeg-turbo-test_1.2.90-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJRTs23AAoJEJr0azAldxsx2bUQALBePsq9vdOIgMqP/C8srW52
6nQMP+62HGJ+9P8ZPloyGqfFKp2AHTZi/7i+5r9+LIjsJWDNNRNznVi0+P3M21vM
eEp2m4dhWvNRhYZXX2rZZTyaZTDm6ChK4fgi1qmEBYHaVaCGJJx6aCVg7+oLcdKA
HNvJE3Y9pRxYsA5gPKmYunFiQ5GdYb1FTgBCknB3O8SbLTJV1hVfA4qmBkwCWyF5
iMjSJSabrcMNS062zRI5m+M6u1j2bgaDsNDSO3/SitzuarSoKqO/f53SR08q8gBb
Cq2VYRw7kRkmfauk1/XLUdeXFoBvdRskUe/vMMjo5iM1lirYregA2ingG2/9GTTX
BlGXElPX07ddxRxtzV+m5zNbIQHh3WJzVJyd57hm57oI9DZ3NDBoqa/GpvoBP34U
TemoAe28KkC83W6xe2vYCDGc5JbJZ5b7cjlZeh1pAH05vtLfV2ILjux1+ysmLmtd
9AiVeXRzCJ40TbIv/EqROssRVhgoTJaJHcG5qSE5drs5TTFoRUU1rxMiBopqvPZ+
7qTXJCz4iYoZZ67uXtjTZZRDq7gt0myO8+DQzHgHD9uKeaY8J9z7XrCXuitHn+LU
gVep0nZBbvpgEsLfxhBjioW7RqyHXiQ+B8c+vUdfGcdA2HEsf25ONHQBbzwNcvmF
7OFc9VOsfq5G/Pp+XgVQ
=KdGP
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.