Bug 1154163 - Review Request: libmozjpeg - SIMD-accelerated JPEG codec that provides both the libjpeg and TurboJPEG APIs
Summary: Review Request: libmozjpeg - SIMD-accelerated JPEG codec that provides both...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Denis Fateyev
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-17 17:25 UTC by Rahul Sundaram
Modified: 2014-11-21 18:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-21 18:53:56 UTC
Type: ---
Embargoed:
denis: fedora-review?


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.