Bug#602034: jpeg8 vs jpeg-turbo
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 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51848a84.3030...@debian.org
Bug#602034: jpeg8 vs jpeg-turbo
On Thu, Apr 25, 2013 at 6:17 AM, Riku Voipio riku.voi...@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 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+7wuszqjfo+ma94e2s_mkzbjduvmvcg+wsbgzhrfghjb5+...@mail.gmail.com
Bug#602034: jpeg8 vs jpeg-turbo
[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. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425152859.ga4...@p12n.org
Bug#602034: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert bill.allomb...@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ý ond...@sury.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caljhhg-6u1y0v50zxuzn-2zcgomxy0dg5qb7cqsyc2m1zlz...@mail.gmail.com
Bug#602034: jpeg8 vs jpeg-turbo
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.allomb...@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.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpxbedkwcBYb.pgp Description: Digitale PGP-Unterschrift
Bug#602034: jpeg8 vs jpeg-turbo
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.gabr...@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.**htmlhttp://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.**htmlhttp://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.**demike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-** netzwerkteam.de.xfbhttps://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)
Bug#602034: jpeg8 vs jpeg-turbo
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ý ond...@sury.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALjhHG9iNiA6kXfo0M+vgo-+xGZjpiX8jNXJguXv=rec9de...@mail.gmail.com
Bug#602034: jpeg8 vs jpeg-turbo
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.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpyFdcnojwGh.pgp Description: Digitale PGP-Unterschrift
Bug#602034: jpeg8 vs jpeg-turbo
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. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424131959.GD3132@yellowpig
Bug#602034: jpeg8 vs jpeg-turbo
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/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424140150.ga31...@afflict.kos.to
Bug#602034: jpeg8 vs jpeg-turbo
On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert bill.allomb...@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 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7KO=g7vi+uymphed5jp9xqxpgtvxaj0-c6_ax-ugz...@mail.gmail.com
Bug#602034: jpeg8 vs jpeg-turbo
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 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130424142644.ga20...@glandium.org
Bug#602034: jpeg8 vs jpeg-turbo
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 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425041740.ga2...@afflict.kos.to
