[RFC] Use libjpeg-turbo in place of libjpeg

[RFC] Use libjpeg-turbo in place of libjpeg

[Maxin B. John]

This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.

libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux
distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently.
lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster)
while maintaining same API/ABI as libjpeg.

Once we reach an agreement on this, based on the decision, we can move the
libjpeg package to meta-oe for applications which may depend on API version 9.

[YOCTO #8628]

Maxin B. John (2):
  libjpeg: Replace libjpeg with libjpeg-turbo
  libjpeg-turbo: import the recipe from meta-oe

 meta/recipes-core/jpeg/jpeg_9a.bb                | 29 -----------------
 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++
 2 files changed, 40 insertions(+), 29 deletions(-)
 delete mode 100644 meta/recipes-core/jpeg/jpeg_9a.bb
 create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb

-- 
2.4.0

[PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo

[Maxin B. John]

Removing libjpeg from oe-core to replace it with libjpeg-turbo.

Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
 meta/recipes-core/jpeg/jpeg_9a.bb | 29 -----------------------------
 1 file changed, 29 deletions(-)
 delete mode 100644 meta/recipes-core/jpeg/jpeg_9a.bb

diff --git a/meta/recipes-core/jpeg/jpeg_9a.bb b/meta/recipes-core/jpeg/jpeg_9a.bb
deleted file mode 100644
index ea2e65d..0000000
--- a/meta/recipes-core/jpeg/jpeg_9a.bb
+++ /dev/null
@@ -1,29 +0,0 @@
-SUMMARY = "libjpeg is a library for handling the JPEG (JFIF) image format"
-DESCRIPTION = "libjpeg contains a library for handling the JPEG (JFIF) image format, as well as related programs for accessing the libjpeg functions."
-HOMEPAGE = "http://www.ijg.org/"
-
-LICENSE ="BSD-3-Clause"
-LIC_FILES_CHKSUM = "file://README;md5=ea93a8a2fed10106b63bc21679edacb9"
-
-SECTION = "libs"
-
-SRC_URI = "http://www.ijg.org/files/jpegsrc.v${PV}.tar.gz \
-	  "
-
-SRC_URI[md5sum] = "3353992aecaee1805ef4109aadd433e7"
-SRC_URI[sha256sum] = "3a753ea48d917945dd54a2d97de388aa06ca2eb1066cbfdc6652036349fe05a7"
-
-inherit autotools
-
-PACKAGES =+ 		"jpeg-tools "
-DESCRIPTION_jpeg-tools = "The jpeg-tools package includes the client programs for access libjpeg functionality.  These tools allow for the compression, decompression, transformation and display of JPEG files."
-FILES_jpeg-tools = 	"${bindir}/*"
-
-BBCLASSEXTEND = "native"
-
-pkg_postinst_${PN}_linuxstdbase () {
-    if [ ! -e $D${libdir}/libjpeg.so.62 ]; then
-        JPEG=`find $D${libdir} -type f -name libjpeg.so.\*.\*.\*`
-        ln -sf `basename $JPEG` $D${libdir}/libjpeg.so.62
-    fi
-}
-- 
2.4.0

[PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe

[Maxin B. John]

libjpeg-turbo has same API/ABI as libjpeg. It is relatively
faster in JPEG compression/decompression than libjpeg.

[YOCTO #8628]

Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb

diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
new file mode 100644
index 0000000..e79f800
--- /dev/null
+++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
@@ -0,0 +1,40 @@
+DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression"
+HOMEPAGE = "http://libjpeg-turbo.org/"
+
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
+                    file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
+                    file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
+"
+
+DEPENDS = "nasm-native"
+
+BASEPV = "${@d.getVar('PV',True).split('+')[1]}"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz"
+SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2"
+SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08"
+
+S = "${WORKDIR}/${BPN}-${BASEPV}"
+
+# Drop-in replacement for jpeg
+PROVIDES = "jpeg"
+RPROVIDES_${PN} += "jpeg"
+RREPLACES_${PN} += "jpeg"
+RCONFLICTS_${PN} += "jpeg"
+
+inherit autotools pkgconfig
+
+EXTRA_OECONF = "--with-jpeg8 "
+
+PACKAGES =+ "jpeg-tools libturbojpeg"
+
+DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality.  These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library."
+FILES_jpeg-tools = "${bindir}/*"
+
+FILES_libturbojpeg = "${libdir}/libturbojpeg.so"
+INSANE_SKIP_libturbojpeg = "dev-so"
+
+BBCLASSEXTEND = "native"
+
+LEAD_SONAME = "libjpeg.so.8"
-- 
2.4.0

Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]

On Fri, Nov 27, 2015 at 01:04:19PM +0200, Maxin B. John wrote:
> libjpeg-turbo has same API/ABI as libjpeg. It is relatively
> faster in JPEG compression/decompression than libjpeg.

Is this imported as-is from meta-oe? If so then at least mention it in
commit message and sent libjpeg-turbo removal for meta-oe.

> 
> [YOCTO #8628]
> 
> Signed-off-by: Maxin B. John <maxin.john@intel.com>
> ---
>  meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> 
> diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> new file mode 100644
> index 0000000..e79f800
> --- /dev/null
> +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> @@ -0,0 +1,40 @@
> +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression"
> +HOMEPAGE = "http://libjpeg-turbo.org/"
> +
> +LICENSE = "BSD-3-Clause"
> +LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
> +                    file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
> +                    file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
> +"
> +
> +DEPENDS = "nasm-native"
> +
> +BASEPV = "${@d.getVar('PV',True).split('+')[1]}"
> +
> +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz"
> +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2"
> +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08"
> +
> +S = "${WORKDIR}/${BPN}-${BASEPV}"
> +
> +# Drop-in replacement for jpeg
> +PROVIDES = "jpeg"
> +RPROVIDES_${PN} += "jpeg"
> +RREPLACES_${PN} += "jpeg"
> +RCONFLICTS_${PN} += "jpeg"
> +
> +inherit autotools pkgconfig
> +
> +EXTRA_OECONF = "--with-jpeg8 "
> +
> +PACKAGES =+ "jpeg-tools libturbojpeg"
> +
> +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality.  These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library."
> +FILES_jpeg-tools = "${bindir}/*"
> +
> +FILES_libturbojpeg = "${libdir}/libturbojpeg.so"
> +INSANE_SKIP_libturbojpeg = "dev-so"
> +
> +BBCLASSEXTEND = "native"
> +
> +LEAD_SONAME = "libjpeg.so.8"
> -- 
> 2.4.0
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe

[Maxin B. John]

Hi Martin,

On Fri, Nov 27, 2015 at 12:14:52PM +0100, Martin Jansa wrote:
> On Fri, Nov 27, 2015 at 01:04:19PM +0200, Maxin B. John wrote:
> > libjpeg-turbo has same API/ABI as libjpeg. It is relatively
> > faster in JPEG compression/decompression than libjpeg.
> 
> Is this imported as-is from meta-oe? If so then at least mention it in
> commit message and sent libjpeg-turbo removal for meta-oe.
> 

Sure, Will do that. This patch set was sent in order to get the opinion from
everyone. Will send the libjpeg-turbo removal patch to meta-oe once it is accepted
in oe-core.

> > 
> > [YOCTO #8628]
> > 
> > Signed-off-by: Maxin B. John <maxin.john@intel.com>
> > ---
> >  meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++
> >  1 file changed, 40 insertions(+)
> >  create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> > 
> > diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> > new file mode 100644
> > index 0000000..e79f800
> > --- /dev/null
> > +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> > @@ -0,0 +1,40 @@
> > +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression"
> > +HOMEPAGE = "http://libjpeg-turbo.org/"
> > +
> > +LICENSE = "BSD-3-Clause"
> > +LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
> > +                    file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
> > +                    file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
> > +"
> > +
> > +DEPENDS = "nasm-native"
> > +
> > +BASEPV = "${@d.getVar('PV',True).split('+')[1]}"
> > +
> > +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz"
> > +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2"
> > +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08"
> > +
> > +S = "${WORKDIR}/${BPN}-${BASEPV}"
> > +
> > +# Drop-in replacement for jpeg
> > +PROVIDES = "jpeg"
> > +RPROVIDES_${PN} += "jpeg"
> > +RREPLACES_${PN} += "jpeg"
> > +RCONFLICTS_${PN} += "jpeg"
> > +
> > +inherit autotools pkgconfig
> > +
> > +EXTRA_OECONF = "--with-jpeg8 "
> > +
> > +PACKAGES =+ "jpeg-tools libturbojpeg"
> > +
> > +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality.  These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library."
> > +FILES_jpeg-tools = "${bindir}/*"
> > +
> > +FILES_libturbojpeg = "${libdir}/libturbojpeg.so"
> > +INSANE_SKIP_libturbojpeg = "dev-so"
> > +
> > +BBCLASSEXTEND = "native"
> > +
> > +LEAD_SONAME = "libjpeg.so.8"
> > -- 
> > 2.4.0
> > 
> > -- 
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Best Regards,
Maxin

Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe

[Jussi Kukkonen]

[-- Attachment #1: Type: text/plain, Size: 3087 bytes --]

On 27 November 2015 at 13:04, Maxin B. John <maxin.john@intel.com> wrote:

> libjpeg-turbo has same API/ABI as libjpeg. It is relatively
> faster in JPEG compression/decompression than libjpeg.
>
> [YOCTO #8628]
>
> Signed-off-by: Maxin B. John <maxin.john@intel.com>
> ---
>  meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40
> ++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
>
> diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> new file mode 100644
> index 0000000..e79f800
> --- /dev/null
> +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> @@ -0,0 +1,40 @@
> +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD
> instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and
> decompression"
> +HOMEPAGE = "http://libjpeg-turbo.org/"
> +
> +LICENSE = "BSD-3-Clause"
> +LIC_FILES_CHKSUM =
> "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
> +
> file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
> +
> file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
> +"
> +
> +DEPENDS = "nasm-native"
> +
> +BASEPV = "${@d.getVar('PV',True).split('+')[1]}"
> +
> +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz"
> +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2"
> +SRC_URI[sha256sum] =
> "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08"
> +
> +S = "${WORKDIR}/${BPN}-${BASEPV}"
> +
> +# Drop-in replacement for jpeg
> +PROVIDES = "jpeg"
> +RPROVIDES_${PN} += "jpeg"
> +RREPLACES_${PN} += "jpeg"
> +RCONFLICTS_${PN} += "jpeg"
> +
> +inherit autotools pkgconfig
> +
> +EXTRA_OECONF = "--with-jpeg8 "
>

It's true that this is closest to what we currently provide but my
understanding of the libjpeg changes is this:
* Both versions 7 and 8 encoders can produce files that are incompatible
with decoders of previous versions
* The major additions in 7 and 8 we're never actually accepted at the
relevant standards body
* most importantly, my impression is that everyone else is using version 6b
(this is also jpeg-turbo upstream default)

I suggest we default to _not_  supporting jpeg8 or jpeg7.

Jussi

+
> +PACKAGES =+ "jpeg-tools libturbojpeg"
> +
> +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs
> to access libjpeg functionality.  These tools allow for the compression,
> decompression, transformation and display of JPEG files and benchmarking of
> the libjpeg library."
> +FILES_jpeg-tools = "${bindir}/*"
> +
> +FILES_libturbojpeg = "${libdir}/libturbojpeg.so"
> +INSANE_SKIP_libturbojpeg = "dev-so"
> +
> +BBCLASSEXTEND = "native"
> +
> +LEAD_SONAME = "libjpeg.so.8"
> --
> 2.4.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 4672 bytes --]

Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe

[Andre McCurdy]

On Fri, Nov 27, 2015 at 3:04 AM, Maxin B. John <maxin.john@intel.com> wrote:
> libjpeg-turbo has same API/ABI as libjpeg. It is relatively
> faster in JPEG compression/decompression than libjpeg.

Please take the libjpeg-turbo 1.4.2 recipe from meta-oe master-next
instead of the 1.4.1 recipe from meta-oe master.

> [YOCTO #8628]
>
> Signed-off-by: Maxin B. John <maxin.john@intel.com>
> ---
>  meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>  create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
>
> diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> new file mode 100644
> index 0000000..e79f800
> --- /dev/null
> +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
> @@ -0,0 +1,40 @@
> +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression"
> +HOMEPAGE = "http://libjpeg-turbo.org/"
> +
> +LICENSE = "BSD-3-Clause"
> +LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
> +                    file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
> +                    file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
> +"
> +
> +DEPENDS = "nasm-native"
> +
> +BASEPV = "${@d.getVar('PV',True).split('+')[1]}"
> +
> +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz"
> +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2"
> +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08"
> +
> +S = "${WORKDIR}/${BPN}-${BASEPV}"
> +
> +# Drop-in replacement for jpeg
> +PROVIDES = "jpeg"
> +RPROVIDES_${PN} += "jpeg"
> +RREPLACES_${PN} += "jpeg"
> +RCONFLICTS_${PN} += "jpeg"
> +
> +inherit autotools pkgconfig
> +
> +EXTRA_OECONF = "--with-jpeg8 "
> +
> +PACKAGES =+ "jpeg-tools libturbojpeg"
> +
> +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality.  These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library."
> +FILES_jpeg-tools = "${bindir}/*"
> +
> +FILES_libturbojpeg = "${libdir}/libturbojpeg.so"
> +INSANE_SKIP_libturbojpeg = "dev-so"
> +
> +BBCLASSEXTEND = "native"
> +
> +LEAD_SONAME = "libjpeg.so.8"
> --
> 2.4.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [RFC] Use libjpeg-turbo in place of libjpeg

[Otavio Salvador]

On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote:
> This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
>
> libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux
> distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently.
> lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster)
> while maintaining same API/ABI as libjpeg.
>
> Once we reach an agreement on this, based on the decision, we can move the
> libjpeg package to meta-oe for applications which may depend on API version 9.

I support this change, due:

 - agreement with major Linux distros
 - performance improvement

I also think moving libjpeg (API version 9) for meta-oe is fine as
well. I am not aware of any application which requires it, though.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [RFC] Use libjpeg-turbo in place of libjpeg

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote:
> On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote:
> > This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
> >
> > libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux
> > distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently.
> > lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster)
> > while maintaining same API/ABI as libjpeg.
> >
> > Once we reach an agreement on this, based on the decision, we can move the
> > libjpeg package to meta-oe for applications which may depend on API version 9.
> 
> I support this change, due:
> 
>  - agreement with major Linux distros
>  - performance improvement
> 
> I also think moving libjpeg (API version 9) for meta-oe is fine as
> well. I am not aware of any application which requires it, though.

I'm not aware of any as well, so I would prefer to drop libjpeg
completely.

+ less junk in meta-oe
+ people were confused about multiple jpeg providers before, now they
would be again, but without good reason (as nobody knows about apps
depending on libjpeg9).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [RFC] Use libjpeg-turbo in place of libjpeg

[Otavio Salvador]

On Fri, Nov 27, 2015 at 9:19 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote:
>> On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote:
>> > This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
>> >
>> > libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux
>> > distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently.
>> > lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster)
>> > while maintaining same API/ABI as libjpeg.
>> >
>> > Once we reach an agreement on this, based on the decision, we can move the
>> > libjpeg package to meta-oe for applications which may depend on API version 9.
>>
>> I support this change, due:
>>
>>  - agreement with major Linux distros
>>  - performance improvement
>>
>> I also think moving libjpeg (API version 9) for meta-oe is fine as
>> well. I am not aware of any application which requires it, though.
>
> I'm not aware of any as well, so I would prefer to drop libjpeg
> completely.
>
> + less junk in meta-oe
> + people were confused about multiple jpeg providers before, now they
> would be again, but without good reason (as nobody knows about apps
> depending on libjpeg9).

Agreed.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [RFC] Use libjpeg-turbo in place of libjpeg

[Maxin B. John]

Hi,

On Fri, Nov 27, 2015 at 12:19:32PM +0100, Martin Jansa wrote:
> On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote:
> > On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote:
> > > This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
> > >
> > > libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux
> > > distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently.
> > > lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster)
> > > while maintaining same API/ABI as libjpeg.
> > >
> > > Once we reach an agreement on this, based on the decision, we can move the
> > > libjpeg package to meta-oe for applications which may depend on API version 9.
> > 
> > I support this change, due:
> > 
> >  - agreement with major Linux distros
> >  - performance improvement
> > 
> > I also think moving libjpeg (API version 9) for meta-oe is fine as
> > well. I am not aware of any application which requires it, though.
> 
> I'm not aware of any as well, so I would prefer to drop libjpeg
> completely.
> 
> + less junk in meta-oe
> + people were confused about multiple jpeg providers before, now they
> would be again, but without good reason (as nobody knows about apps
> depending on libjpeg9).
>

Agree. In this case, I will send a patch to remove libjpeg-turbo from meta-oe.

> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Best Regards,
Maxin

Re: [RFC] Use libjpeg-turbo in place of libjpeg

[Mike Looijmans]

On 27-11-15 12:19, Martin Jansa wrote:
> On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote:
>> On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote:
>>> This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
>>>
>>> libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux
>>> distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently.
>>> lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster)
>>> while maintaining same API/ABI as libjpeg.
>>>
>>> Once we reach an agreement on this, based on the decision, we can move the
>>> libjpeg package to meta-oe for applications which may depend on API version 9.
>>
>> I support this change, due:
>>
>>   - agreement with major Linux distros
>>   - performance improvement
>>
>> I also think moving libjpeg (API version 9) for meta-oe is fine as
>> well. I am not aware of any application which requires it, though.
>
> I'm not aware of any as well, so I would prefer to drop libjpeg
> completely.
>
> + less junk in meta-oe
> + people were confused about multiple jpeg providers before, now they
> would be again, but without good reason (as nobody knows about apps
> depending on libjpeg9).

Indeed, most (read: "I") have set the PREFERRED_SUPPLIER to "jpeg" just to get 
rid of the warning message, and not really bothering to check what either meant.

I'm in favor of dropping libjpeg completely, it's just confusing.

Moving it will lead to package dependency problems when upgrading from one to 
the other.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail