Bug 1154163

Summary:	Review Request: libmozjpeg - SIMD-accelerated JPEG codec that provides both the libjpeg and TurboJPEG APIs
Product:	[Fedora] Fedora	Reporter:	Rahul Sundaram <metherid>
Component:	Package Review	Assignee:	Denis Fateyev <denis>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	denis, kevin, musuruan, package-review
Target Milestone:	---	Flags:	denis: fedora-review?
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-11-21 18:53:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rahul Sundaram 2014-10-17 17:25:17 UTC

Spec URL: https://sundaram.fedorapeople.org/packages/libmozjpeg.spec
SRPM URL: https://sundaram.fedorapeople.org/packages/libmozjpeg-2.1-1.fc21.src.rpm
Description:

libmozjpeg is a JPEG image codec that uses SIMD instructions (MMX, SSE2,
NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64,
and ARM systems.  On such systems, libmozjpeg is generally 2-4x as fast as
libjpeg, all else being equal.  On other types of systems, libmozjpeg can
still outperform libjpeg by a significant amount, by virtue of its
highly-optimized Huffman coding routines.  In many cases, the performance of
libmozjpeg rivals that of proprietary high-speed JPEG codecs.

libmozjpeg implements both the traditional libjpeg API as well as the less
powerful but more straightforward TurboJPEG API.  libmozjpeg also features
colorspace extensions that allow it to compress from/decompress to 32-bit and
big-endian pixel buffers (RGBX, XBGR, etc.), as well as a full-featured Java
interface.

libmozjpeg was forked from libjpeg-turbo.

Fedora Account System Username: sundaram

Comment 1 Rahul Sundaram 2014-10-17 18:56:50 UTC

Scratch build

http://koji.fedoraproject.org/koji/taskinfo?taskID=7897844

Comment 2 Rahul Sundaram 2014-10-17 20:33:26 UTC

Second scratch build

http://koji.fedoraproject.org/koji/taskinfo?taskID=7899282

Had to disable the tests because it hung indefinitely.

Comment 3 Rahul Sundaram 2014-10-17 20:46:38 UTC

rpmlint:

Checking: libmozjpeg-2.1-1.fc21.x86_64.rpm
          libmozjpeg-utils-2.1-1.fc21.x86_64.rpm
          libmozjpeg-devel-2.1-1.fc21.x86_64.rpm
          libmozjpeg-2.1-1.fc21.src.rpm
libmozjpeg.x86_64: W: spelling-error Summary(en_US) codec -> codex, code, codes
libmozjpeg.x86_64: W: spelling-error Summary(en_US) libjpeg -> libel
libmozjpeg.x86_64: W: spelling-error %description -l en_US codec -> codex, code, codes
libmozjpeg.x86_64: W: spelling-error %description -l en_US libjpeg -> libel
libmozjpeg.x86_64: W: spelling-error %description -l en_US codecs -> codes, coders, code's
libmozjpeg.x86_64: W: spelling-error %description -l en_US colorspace -> color space, color-space, colors pace
libmozjpeg.x86_64: W: spelling-error %description -l en_US endian -> Indian, Dianne, Diane
libmozjpeg.x86_64: W: shared-lib-calls-exit /usr/lib64/libturbojpeg.so.0.1.0 exit.5
libmozjpeg.x86_64: W: shared-lib-calls-exit /usr/lib64/libjpeg.so.62.1.0 exit.5
libmozjpeg-utils.x86_64: W: spelling-error %description -l en_US libjpeg -> libel
libmozjpeg-utils.x86_64: W: spelling-error %description -l en_US Cjpeg -> Peg
libmozjpeg-utils.x86_64: W: spelling-error %description -l en_US Djpeg -> Pegged
libmozjpeg-utils.x86_64: W: spelling-error %description -l en_US Jpegtran -> Registrant
libmozjpeg-utils.x86_64: W: spelling-error %description -l en_US Rdjpgcom 
libmozjpeg-utils.x86_64: W: spelling-error %description -l en_US Wrjpgcom 
libmozjpeg-utils.x86_64: W: no-manual-page-for-binary tjbench
libmozjpeg-devel.x86_64: W: only-non-binary-in-usr-lib
libmozjpeg.src: W: spelling-error Summary(en_US) codec -> codex, code, codes
libmozjpeg.src: W: spelling-error Summary(en_US) libjpeg -> libel
libmozjpeg.src: W: spelling-error %description -l en_US codec -> codex, code, codes
libmozjpeg.src: W: spelling-error %description -l en_US libjpeg -> libel
libmozjpeg.src: W: spelling-error %description -l en_US codecs -> codes, coders, code's
libmozjpeg.src: W: spelling-error %description -l en_US colorspace -> color space, color-space, colors pace
libmozjpeg.src: W: spelling-error %description -l en_US endian -> Indian, Dianne, Diane
4 packages and 0 specfiles checked; 0 errors, 24 warnings.


Source checksums
----------------
https://github.com/mozilla/mozjpeg/archive/v2.1.tar.gz :
  CHECKSUM(SHA256) this package     : f3d5413a5fc94990994e1cb9c8817e47f8508f5a4ae3c124628e309d1873bec3
  CHECKSUM(SHA256) upstream package : f3d5413a5fc94990994e1cb9c8817e47f8508f5a4ae3c124628e309d1873bec3

Comment 4 Rahul Sundaram 2014-10-17 21:17:28 UTC

Additional note,  currently libmozjpeg has an explicit conflict with libjpeg-turbo, however this will be fixed in the future when upstream documents ABI compatibility with the latter


https://github.com/mozilla/mozjpeg/issues/21
https://github.com/mozilla/mozjpeg/issues/67

Comment 5 Andrea Musuruane 2014-10-19 20:15:51 UTC

Utils package description is wrong. It refers to libjpeg-turbo and not to libmozjpeg.

Comment 6 Rahul Sundaram 2014-10-19 20:33:10 UTC

fixed

Comment 7 Kevin Kofler 2014-10-22 02:44:27 UTC

A Conflicts with a core system library against which half of Fedora is linked is not acceptable. This can only go in if API compatibility is guaranteed (or the soname is bumped, but then it would lose soname compatibility with libjpeg 6.2, which would suck) and the Conflicts changed to an Obsoletes.

Comment 8 Kevin Kofler 2014-10-22 02:47:31 UTC

> This can only go in if API compatibility is guaranteed (or the soname is
> bumped, but then it would lose soname compatibility with libjpeg 6.2, which
> would suck)

… or if they follow through with their plans of renaming the library altogether, in which case it would just be a separate library from libjpeg(-turbo) and neither Conflict with nor Obsolete libjpeg-turbo. (Only symbol conflicts could be an issue in that case.)

Comment 9 Denis Fateyev 2014-10-22 05:00:36 UTC

(In reply to Kevin Kofler from comment #8)
> if they follow through with their plans of renaming the library
> altogether, in which case it would just be a separate library from
> libjpeg(-turbo) and neither Conflict with nor Obsolete libjpeg-turbo.

That would be the best approach here. Although I doubt they would rename the library. Considering all that above said I think the package cannot be accepted in its current state.

Comment 10 Rahul Sundaram 2014-11-21 18:53:56 UTC

Will revisit this if situation changes.