Hello community, here is the log from the commit of package libjpeg-turbo for openSUSE:Factory checked in at 2019-10-14 12:30:55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/libjpeg-turbo (Old) and /work/SRC/openSUSE:Factory/.libjpeg-turbo.new.2352 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "libjpeg-turbo" Mon Oct 14 12:30:55 2019 rev:49 rq:735600 version:unknown Changes: -------- --- /work/SRC/openSUSE:Factory/libjpeg-turbo/libjpeg-turbo.changes 2019-03-28 22:44:49.087091337 +0100 +++ /work/SRC/openSUSE:Factory/.libjpeg-turbo.new.2352/libjpeg-turbo.changes 2019-10-14 12:30:58.136352144 +0200 @@ -1,0 +2,34 @@ +Sat Oct 5 09:08:03 UTC 2019 - Bjørn Lie <[email protected]> + +- 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. + +------------------------------------------------------------------- --- /work/SRC/openSUSE:Factory/libjpeg-turbo/libjpeg62-turbo.changes 2019-01-08 12:19:11.388885578 +0100 +++ /work/SRC/openSUSE:Factory/.libjpeg-turbo.new.2352/libjpeg62-turbo.changes 2019-10-14 12:30:58.172352050 +0200 @@ -1,0 +2,34 @@ +Sat Oct 5 09:08:29 UTC 2019 - Bjørn Lie <[email protected]> + +- 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. + +------------------------------------------------------------------- Old: ---- libjpeg-turbo-2.0.2.tar.gz libjpeg-turbo-2.0.2.tar.gz.sig New: ---- libjpeg-turbo-2.0.3.tar.gz libjpeg-turbo-2.0.3.tar.gz.sig ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ libjpeg-turbo.spec ++++++ --- /var/tmp/diff_new_pack.PSXipR/_old 2019-10-14 12:30:58.836350320 +0200 +++ /var/tmp/diff_new_pack.PSXipR/_new 2019-10-14 12:30:58.840350309 +0200 @@ -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.spec ++++++ --- /var/tmp/diff_new_pack.PSXipR/_old 2019-10-14 12:30:58.860350258 +0200 +++ /var/tmp/diff_new_pack.PSXipR/_new 2019-10-14 12:30:58.864350247 +0200 @@ -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} ++++++ libjpeg-turbo-2.0.2.tar.gz -> libjpeg-turbo-2.0.3.tar.gz ++++++ ++++ 4135 lines of diff (skipped)
