update: graphics/jpeg, mips64el test wanted

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

update: graphics/jpeg, mips64el test wanted

Stuart Henderson
This seems like it should be a straightforward update, but the asm changes
for mips64el mean it would be prudent to get at least a build test there,
can anyone help please?

2.0.2
=====

### Significant changes relative to 2.0.1:

1. Fixed a regression introduced by 2.0.1[5] that prevented a runtime search
path (rpath) from being embedded in the libjpeg-turbo shared libraries and
executables for macOS and iOS.  This caused a fatal error of the form
"dyld: Library not loaded" when attempting to use one of the executables,
unless `DYLD_LIBRARY_PATH` was explicitly set to the location of the
libjpeg-turbo shared libraries.

2. Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that
occurred when attempting to load a BMP file with more than 1 billion pixels
using the `tjLoadImage()` function.

3. Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to
decompress a specially-crafted malformed JPEG image to a 256-color BMP using
djpeg.

4. Fixed a floating point exception that occurred when attempting to
decompress a specially-crafted malformed JPEG image with a specified image
width or height of 0 using the C version of TJBench.

5. The TurboJPEG API will now decompress 4:4:4 JPEG images with 2x1, 1x2, 3x1,
or 1x3 luminance and chrominance sampling factors.  This is a non-standard way
of specifying 1x subsampling (normally 4:4:4 JPEGs have 1x1 luminance and
chrominance sampling factors), but the JPEG format and the libjpeg API both
allow it.

6. Fixed a regression introduced by 2.0 beta1[7] that caused djpeg to generate
incorrect PPM images when used with the `-colors` option.

7. Fixed an issue whereby a static build of libjpeg-turbo (a build in which
`ENABLE_SHARED` is `0`) could not be installed using the Visual Studio IDE.

8. Fixed a severe performance issue in the Loongson MMI SIMD extensions that
occurred when compressing RGB images whose image rows were not 64-bit-aligned.

source diff: https://pbot.rmdir.de/u/VN7rIW4KdGlWDuIN1glFBw




Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/jpeg/Makefile,v
retrieving revision 1.61
diff -u -p -r1.61 Makefile
--- Makefile 13 Nov 2018 14:30:43 -0000 1.61
+++ Makefile 15 Feb 2019 16:27:49 -0000
@@ -2,7 +2,7 @@
 
 COMMENT= SIMD-accelerated JPEG codec replacement of libjpeg
 
-V= 2.0.1
+V= 2.0.2
 DISTNAME= jpeg-turbo-${V}
 PKGNAME= jpeg-${V}
 EPOCH= 0
Index: distinfo
===================================================================
RCS file: /cvs/ports/graphics/jpeg/distinfo,v
retrieving revision 1.15
diff -u -p -r1.15 distinfo
--- distinfo 13 Nov 2018 14:30:43 -0000 1.15
+++ distinfo 15 Feb 2019 16:27:49 -0000
@@ -1,2 +1,2 @@
-SHA256 (libjpeg-turbo-2.0.1.tar.gz) = 5fhs7DHfHTlZbgzKYZqxsB+ZAlon2v38l6MPOhL4Zv8=
-SIZE (libjpeg-turbo-2.0.1.tar.gz) = 2159130
+SHA256 (libjpeg-turbo-2.0.2.tar.gz) = rLhZn+U5mvEUKH7lkHrqRFb48sHMltJsKK6/317oL+0=
+SIZE (libjpeg-turbo-2.0.2.tar.gz) = 2159562

Reply | Threaded
Open this post in threaded view
|

Re: update: graphics/jpeg, mips64el test wanted

Matthieu Herrb-3
On Fri, Feb 15, 2019 at 04:29:29PM +0000, Stuart Henderson wrote:
> This seems like it should be a straightforward update, but the asm changes
> for mips64el mean it would be prudent to get at least a build test there,
> can anyone help please?

I've started a build yesterday on my loongson, but I didn't realize
that it would  need cmake and thus gcc 4.9. The build is still
running. I'll let you know the result when it's done (unless someone
beats me).

--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: update: graphics/jpeg, mips64el test wanted

Matthieu Herrb-3
On Sat, Feb 16, 2019 at 09:36:08AM +0100, Matthieu Herrb wrote:

> On Fri, Feb 15, 2019 at 04:29:29PM +0000, Stuart Henderson wrote:
> > This seems like it should be a straightforward update, but the asm changes
> > for mips64el mean it would be prudent to get at least a build test there,
> > can anyone help please?
>
> I've started a build yesterday on my loongson, but I didn't realize
> that it would  need cmake and thus gcc 4.9. The build is still
> running. I'll let you know the result when it's done (unless someone
> beats me).
>

The build finished, jpeg 2.0.2 built ok and runs ok (tested with xv).
The full build log is here: https://herrb.eu/jpeg-2.0.2v0.log

The cmake checks for simd fail so afaict the mipsel assembly is not
used.

--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: update: graphics/jpeg, mips64el test wanted

Stuart Henderson
On 2019/02/17 17:05, Matthieu Herrb wrote:

> On Sat, Feb 16, 2019 at 09:36:08AM +0100, Matthieu Herrb wrote:
> > On Fri, Feb 15, 2019 at 04:29:29PM +0000, Stuart Henderson wrote:
> > > This seems like it should be a straightforward update, but the asm changes
> > > for mips64el mean it would be prudent to get at least a build test there,
> > > can anyone help please?
> >
> > I've started a build yesterday on my loongson, but I didn't realize
> > that it would  need cmake and thus gcc 4.9. The build is still
> > running. I'll let you know the result when it's done (unless someone
> > beats me).
> >
>
> The build finished, jpeg 2.0.2 built ok and runs ok (tested with xv).
> The full build log is here: https://herrb.eu/jpeg-2.0.2v0.log
>
> The cmake checks for simd fail so afaict the mipsel assembly is not
> used.

Great, thank you.