Accepting request 735600 from graphics

New upstream release (forwarded request 735401 from iznogood)

OBS-URL: https://build.opensuse.org/request/show/735600
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/libjpeg-turbo?expand=0&rev=49

libjpeg-turbo-2.0.2.tar.gz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:acb8599fe5399af114287ee5907aea4456f8f2c1cc96d26c28aebfdf5ee82fed
-size 2159562

libjpeg-turbo-2.0.3.tar.gz

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:4246de500544d4ee408ee57048aa4aadc6f165fc17f141da87669f20ed3241b7
+size 2161279

libjpeg-turbo.changes

@@ -1,3 +1,37 @@
+-------------------------------------------------------------------
+Sat Oct  5 09:08:03 UTC 2019 - Bjørn Lie <bjorn.lie@gmail.com>
+
+- Update to version 2.0.3:
+  * Fixed "using JNI after critical get" errors that occurred on
+    Android platforms when passing invalid arguments to certain
+    methods in the TurboJPEG Java API.
+  * Fixed a regression in the SIMD feature detection code,
+    introduced by the AVX2 SIMD extensions (2.0 beta1), that was
+    known to cause an illegal instruction exception, in rare cases,
+    on CPUs that lack support for CPUID leaf (or on which the
+    maximum CPUID leaf has been limited by way of a BIOS setting.)
+  * The 4:4:0 (h1v2) fancy (smooth) chroma upsampling algorithm in
+    the decompressor now uses a similar bias pattern to that of the
+    4:2:2 (h2v1) fancy chroma upsampling algorithm, rounding up or
+    down the upsampled result for alternate pixels rather than
+    always rounding down. This ensures that, regardless of whether
+    a 4:2:2 JPEG image is rotated or transposed prior to
+    decompression (in the frequency domain) or after decompression
+   (in the spatial domain), the final image will be similar.
+  * Fixed an integer overflow and subsequent segfault that occurred
+    when attempting to compress or decompress images with more than
+    1 billion pixels using the TurboJPEG API.
+  * Fixed a regression introduced by 2.0 beta1[15] whereby
+    attempting to generate a progressive JPEG image on an
+    SSE2-capable CPU using a scan script containing one or more
+    scans with lengths divisible by 16 would result in an error
+    ("Missing Huffman code table entry") and an invalid JPEG image.
+  * Fixed an issue whereby `tjDecodeYUV()` and
+    `tjDecodeYUVPlanes()` would throw an error ("Invalid
+    progressive parameters") or a warning ("Inconsistent
+    progression sequence") if passed a TurboJPEG instance that was
+    previously used to decompress a progressive JPEG image.
+
 -------------------------------------------------------------------
 Wed Mar 27 06:46:43 UTC 2019 - pgajdos@suse.com
 

libjpeg-turbo.spec

@@ -19,7 +19,7 @@
 %define asan_build 0
 %define debug_build 0
 
-%define srcver   2.0.2
+%define srcver   2.0.3
 %define major    8
 %define minor    2
 %define micro    2

libjpeg62-turbo.changes

@@ -1,3 +1,37 @@
+-------------------------------------------------------------------
+Sat Oct  5 09:08:29 UTC 2019 - Bjørn Lie <bjorn.lie@gmail.com>
+
+- Update to version 2.0.3:
+  * Fixed "using JNI after critical get" errors that occurred on
+    Android platforms when passing invalid arguments to certain
+    methods in the TurboJPEG Java API.
+  * Fixed a regression in the SIMD feature detection code,
+    introduced by the AVX2 SIMD extensions (2.0 beta1), that was
+    known to cause an illegal instruction exception, in rare cases,
+    on CPUs that lack support for CPUID leaf (or on which the
+    maximum CPUID leaf has been limited by way of a BIOS setting.)
+  * The 4:4:0 (h1v2) fancy (smooth) chroma upsampling algorithm in
+    the decompressor now uses a similar bias pattern to that of the
+    4:2:2 (h2v1) fancy chroma upsampling algorithm, rounding up or
+    down the upsampled result for alternate pixels rather than
+    always rounding down. This ensures that, regardless of whether
+    a 4:2:2 JPEG image is rotated or transposed prior to
+    decompression (in the frequency domain) or after decompression
+   (in the spatial domain), the final image will be similar.
+  * Fixed an integer overflow and subsequent segfault that occurred
+    when attempting to compress or decompress images with more than
+    1 billion pixels using the TurboJPEG API.
+  * Fixed a regression introduced by 2.0 beta1[15] whereby
+    attempting to generate a progressive JPEG image on an
+    SSE2-capable CPU using a scan script containing one or more
+    scans with lengths divisible by 16 would result in an error
+    ("Missing Huffman code table entry") and an invalid JPEG image.
+  * Fixed an issue whereby `tjDecodeYUV()` and
+    `tjDecodeYUVPlanes()` would throw an error ("Invalid
+    progressive parameters") or a warning ("Inconsistent
+    progression sequence") if passed a TurboJPEG instance that was
+    previously used to decompress a progressive JPEG image.
+
 -------------------------------------------------------------------
 Thu Jan  3 16:46:46 UTC 2019 - Petr Gajdos <pgajdos@suse.com>
 

libjpeg62-turbo.spec

@@ -19,7 +19,7 @@
 %define major   62
 %define minor   3
 %define micro   0
-%define srcver  2.0.2
+%define srcver  2.0.3
 %define libver  %{major}.%{minor}.%{micro}
 Name:           libjpeg62-turbo
 Version:        %{srcver}