Your message dated Thu, 31 Jul 2014 19:24:29 -0700 with message-id <20140801022429.GE12356@teltox.donarmstrong.com> and subject line [CTTE #717076] Default libjpeg implementation in Debian has caused the Debian Bug report #717076, regarding tech-ctte: Decide what jpeg library the Debian project will use to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 717076: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717076 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: tech-ctte: Decide what jpeg library the Debian project will use
- From: Ondřej Surý <ondrej@debian.org>
- Date: Tue, 16 Jul 2013 16:08:33 +0200
- Message-id: <20130716140833.24284.26198.reportbug@howl.nic.cz>
Package: tech-ctte Severity: normal -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Technical Committee, I have raised the question of libjpeg8 vs. jpeg-turbo as a default libjpeg library for Debian in debian-devel[1], but we were not able to reach a consensus. I spoke to our DPL and he recommended to fill a tech-ctte bug, since this is exactly the kind of problems the tech-ctte should have final word. 1. <CALjhHG9iNiA6kXfo0M+vgo-+xGZjpiX8jNXJguXv=REc9deGew@mail.gmail.com> The current libjpeg* world looks like this (Bill please correct me if I made a mistake somewhere). There's a IJG libjpeg implementation (where IJG has nothing to do with former IJG which created libjpeg6). The current maintainer (Guido Vollbeding) of IJG libjpeg is adding library features not blessed by JPEG commitee and he seems to add new features he pushes without coordination of ISO (SmartScale). Also it seems that current IJG is not very healthy open-source project - the upstream maintainer seems to be hostile and there's no bug tracker, no mailing list, no online repository, no instructions how to propose new feature, where to send bugfixes etc. See my unanswered questions in: <CALjhHG-6u1y0V50ZxUzn-2ZCgoMxy0dg5Qb7cQSyc2M1ZLZ7eg@mail.gmail.com> Also the ISO committe has rejected the changes made by libjpeg8: http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html The other implementation - libjpeg-turbo[2] is a green field 2-4 times faster reimplementation of libjpeg62 (with added support for libjpeg8 ABI). Most of other Linux distributions (Fedora[3], Ubuntu and SuSE, maybe others). My view is that libjpeg-turbo is much conservative when adding new features to it. 2. http://libjpeg-turbo.virtualgl.org/ 3. https://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html Since the release team (and I understand them) doesn't want to have more than one libjpeg library in Debian this needs to be decided by independent party, since Bill has declared he wants to have IJG libjpeg as default (and bump the SONAME yet again to libjpeg9). My proposal is to switch the default libjpeg library to libjpeg-turbo to achieve several goals: 1. to have faster libjpeg implementation 2. to have upstream which is community driven and community friendly 3. to align with other distros 4. to not have upstream which bumps SONAME to push his own new features incompatible with ISO JPEG standard I think we can use the libjpeg8 compatibility layer of libjpeg-turbo. Although I am not sure if it is really needed as there was only one package needing new API from libjpeg8 I have heard and that should be trivial to fix. Ondrej - -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHlU+EACgkQ9OZqfMIN8nMoGACgoG5FPCpvZOfBDc/fAVXjhmyy 8MoAni1zEaeFrqofJghCHbR9kPV8y0In =SwHG -----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
- To: debian-devel-announce@lists.debian.org
- Subject: [CTTE #717076] Default libjpeg implementation in Debian
- From: Don Armstrong <don@debian.org>
- Date: Thu, 31 Jul 2014 19:24:29 -0700
- Message-id: <20140801022429.GE12356@teltox.donarmstrong.com>
- Mail-followup-to: debian-ctte@lists.debian.org
The technical committee was asked in #717076 to decide whether libjpeg8 or libjpeg-turbo would be the default libjpeg implementation. The decision is below: ==== RESOLUTION ==== Whereas: 1. There is a dispute between Developers about whether libjpeg8/9 or libjpeg-turbo should be the default libjpeg implementation in Debian. The release team does not want to have more than one libjpeg implementation. 2. The Debian libjpeg8 maintainer does not see libjpeg-turbo as a suitable replacement, and notes that it does not implement the full libjpeg8/9 ABI. 3. libjpeg8 adds new features to the JPEG image format. These have however been rejected from the ISO standard, and their contributions to image quality and compression appear to be widely disputed. 4. libjpeg-turbo is reported to have significantly better performance than libjpeg, and to be API/ABI-compatible with libjpeg6b. 5. libjpeg-turbo is in use by several other distributions (at least Fedora, Gentoo, openSUSE, Ubuntu) and browser projects (WebKit, Blink, Gecko). 6. The former organiser of the IJG advised Fedora of his opinion that libjpeg8 was a "dead end" due to fragmentation. 7. The libjpeg-turbo packages in Debian are not yet in a state where they could be a drop-in replacement for libjpeg8. However, similar work has been done in Ubuntu and could be adopted. 8. In general it does not appear that other Debian packages require the libjpeg8 API. The sole exception appears to be a "decode from memory buffer" interface (jpeg_mem_src/jpeg_mem_dest), which is implemented by libjpeg-turbo unless configured --without-mem-srcdst. 9. While libjpeg-turbo can be configured with support for much of the newer interfaces in libjpeg8, it does not support the SmartScale API. However, images with this extension may have interoperability problems. Those developers advocating libjpeg-turbo generally suggest disabling the libjpeg7/libjpeg8 APIs there. Therefore: 10. The Technical Committee resolves that libjpeg-turbo should become the libjpeg implementation in Debian, using its power under 6.1(2) to decide on technical matters of overlapping jurisdiction. 11. The prospective libjpeg-turbo maintainer should propose an appropriate transition plan for this change, and, after a reasonable period for comment, prepare tested packages for upload. The transition plan should state the timescales for the relevant changes. 12. Implementing the decision in 10 above will require removing "Provides: libjpeg-dev" from libjpeg8, since such a virtual package must be provided by only one real package at a time. Therefore the Provides should be removed from the libjpeg8 package - in accordance with the transition plan - notwithstanding the libjpeg8 maintainer's preference that libjpeg8 should remain as the default libjpeg. This change should be made by the libjpeg8 maintainer; if the change is not made within a reasonable time it should be done in an NMU by the libjpeg-turbo maintainer. ==== END OF RESOLUTION ==== Please see http://bugs.debian.org/717076 for discussion of this bug.Attachment: signature.asc
Description: Digital signature
--- End Message ---