Bug 1001399 - OpenJPEG 2.0 has been released
OpenJPEG 2.0 has been released
Status: CLOSED DUPLICATE of bug 1084021
Product: Fedora
Classification: Fedora
Component: openjpeg (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaromír Cápík
Fedora Extras Quality Assurance
: FutureFeature
: 878782 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-26 20:56 EDT by Christopher Meng
Modified: 2016-01-31 20:59 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-03 14:42:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christopher Meng 2013-08-26 20:56:31 EDT
Upstream has released 2.0 in 2012.

http://www.openjpeg.org/index.php?menu=download

Please update.
Comment 1 Jaromír Cápík 2013-09-12 12:52:23 EDT
Hello Christopher.

openjpeg-2.0 is backward incompatible with openjpeg-1.5.1

Look at the report:
http://upstream-tracker.org/compat_reports/openjpeg/1.5.1_to_2.0.0/abi_compat_report.html

The library is used by several projects which would need to be patched to work with the new version and that means it needs someone who has a lot of free time or waiting till the dependent upstream projects decide to migrate to the new version without our intervention.

Regards,
Jaromir.
Comment 2 Rex Dieter 2013-09-12 13:03:54 EDT
Dont confuse ABI *binary* compatiblity with API *source* compatibility.

ABI change/breakage means stuff only needs to be rebuilt.

API change/breakage means porting code.
Comment 3 Rex Dieter 2013-09-12 13:07:05 EDT
(co)maintainers welcome, for what it's worth... haven't had a chance to work on this one in awhile.
Comment 4 Jaromír Cápík 2013-09-12 13:43:44 EDT
Hi Rex.

I agree the report link might be a bit confusing. If you look at the report, you could see it covers API changes as well. There are missing symbols which cannot be resolved by rebuilding.

Regards,
Jaromir.
Comment 5 Rex Dieter 2013-09-12 13:56:07 EDT
depends if those symbols were part of the public api or not. but point taken, you know what you're doing. :)
Comment 6 Pablo Rodríguez 2013-09-24 01:17:20 EDT
Hi Jaromir,

I guess bug 878782 is a duplicate of this one.

BTW, wouldn’t it be possible to package also openjpeg-2.0 as a different library from openjpeg-1.5?

Among other potential projects, mupdf would benefit from this (bug 848904).

Many thanks for your help,


Pablo
Comment 7 Jaromír Cápík 2013-09-24 09:32:37 EDT
Hi Pablo.

In fact this one duplicates the Bug 878782, but as this bug contains more info, I'm going to close the upstream monitoring report.

Regarding the packaging as a different library ... It seems neither the headers, nor the library would conflict, but this would for sure introduce more mess in the distro and I believe it's messed enough. So, I'm not a big fan of that solution. It's a pity, that the v2 doesn't contain any compat layer for backward compatibility with v1.5 dependent projects. It would be much easier to do the migration.

Regards,
Jaromir.
Comment 8 Jaromír Cápík 2013-09-24 09:41:15 EDT
We might potentially do the upgrade to 2.0 and include 1.5 in form of *-1.5_compat subpackage (we can remove it once all the dependent projects have support for 2.x). However, this solution seems to me a bit perverted.

Rex, what do you think?
Comment 9 Jaromír Cápík 2013-09-24 09:47:30 EDT
*** Bug 878782 has been marked as a duplicate of this bug. ***
Comment 10 Rex Dieter 2013-09-24 17:08:35 EDT
I would be against any compat packages, until there is a demonstrated need for them.
Comment 11 Jaromír Cápík 2013-10-01 08:02:07 EDT
The mupdf-1.3 changelog lists the following improvements. Some of them are minor, some of them look major. I consider that a sufficient demonstration, but I'm still kinda undecided ... I understand the benefits, but as it means that all dependent packages would have to be modified and rebuilt, I see this as a lot of effort and negotiation and asking myself if it is worthy enough for doing such change. Moreover, even if I have rights to do the changes in the dependent packages directly, I don't want to touch the dependent packages without (at least) discussing the changes with the package owners.

------------------------------------------

List of changes on master since MuPDF 1.2

 * Windows RT viewer app for MuPDF.
 * Library changes to support progressive loading (display PDF files as
   they download). Windows/Linux/MacOS viewer supports this using curl.
 * Incremental updates to PDF files are now (optionally) preserved on
   loading/saving.
 * Prototype support for checking PDF Digital Signatures.
 * Initial annotation support (strike-out, underline, highlight and ink)
   (library and android builds only).
 * Fix operation on Android API level 8.
 * Android redraw optimisations.
 * Android app now supports Google Cloud Print.
 * Android app translated into many languages.
 * Android support for more architectures.
 * Improvements to store (avoid collisions causing unnecessary evictions).
 * Windows apps use Unicode filenames now.
 * PDF function handling improved; functions can now be passed to devices
   without 'sampling'.
 * PDF image handling improved; images can now be passed to devices
   without decompression.
 * Indexed images are no longer uncompressed at load time, saving memory.
 * Caching of rendered tiles for speed.
 * Improved text analysis mode, capable of spotting columns/indents,
   right-to-left text etc.
 * HTML output mode now includes image output.
 * PDF password encoding handling improved.
 * MuPDF now opens Jpeg, Tiff and PNG files directly.
 * Bug preventing OpenXPS files from being opened fixed.
 * Initial (feature incomplete) SVG and PDF output devices.
 * PWG raster (mono/grey/RGB) and PCL (mono) output devices.
 * Various performance improvements (including tilings and mesh based
   shadings).
 * Revamped directory structure to reflect recent changes.
 * Various potential SEGV, SoftMask and rendering fixes.
 * Many potential crashes in Jpeg2000 and JBIG2 images fixed.
Comment 12 Pablo Rodríguez 2013-11-03 15:04:44 EST
Hi Jaromír,

sorry for not having answered before.

I’m not sure whether I understand the incompatibility. I’m only an average user, but I’m really interested on this issue.

Is it only a binary incompatibility or does the code need to be adapted?

Many thanks for your help,


Pablo
Comment 13 Jaromír Cápík 2013-11-07 11:50:18 EST
Hi Pablo.

A subset of packages depending on the openjpeg-1.5 would have to be adapted in order to work with the openjpeg-2.0 library. At the moment we have no accurate stats relevant for the Fedora repository, but my guess (according to the API/ABI compliance checker) is that it could affect more than a half of them. And that for sure is a lot of work.

Regards,
Jaromir.
Comment 14 Pablo Rodríguez 2013-11-07 12:03:29 EST
Hi Jaromír,

I cannot code so I can’t help with the migration. Sorry.

I don’t understand why openjpeg2 cannot be packaged (in parallel with openjpeg) the same way that Fedora different versions of incompatible libraries: gtk, kde and others.

I think the key point here is that the packaging request is not for an older version of the library, but for its latest release.

I agree that is not the perfect solution, but we live in a world far from being perfect (at least, it was so last time I checked :-)).

Many thanks for your help,


Pablo
Comment 15 Jaromír Cápík 2013-11-26 11:04:12 EST
Hi Pablo.

Two concurrent versions of libraries mean more mess in the distro, need for a new formal component review, probability of introducing new unexpected build conflicts and therefore it's questionable whether it's easier than porting the software to openjpeg-2.x. The importance of having two concurrent versions of OpenJPEG library is much lower than importance of having two concurrent versions of GUI toolkits like GTK/Qt and that's why we'd like to avoid that if possible. At the moment I think the pros do not clearly beat the cons.

Regards,
Jaromir.
Comment 16 Christopher Meng 2014-03-09 11:29:55 EDT
A list of affected packages:

blender
blenderplayer
calligra-core
calligra-krita
darktable
#ffmpeg-compat
#ffmpeg-libs
freeimage (my package)
gdcm
gpac-libs
mtpaint
mupdf
OpenImageIO
openslide
poppler
vfrnav
xpaint
Comment 17 Rex Dieter 2014-03-31 12:39:24 EDT
I withdraw my initial objection to parallel-installable pkgs, I'd welcome some openjpeg2 pkg, and would be willing to help make sure it plays nice with any existing openjpeg(1) packaging.
Comment 18 Sandro Mani 2014-04-03 08:42:39 EDT
Since python-pillow has added openjpeg (2.0 only) support, I've given it a go at packaging openjpeg-2.0:

https://bugzilla.redhat.com/show_bug.cgi?id=1084021
Comment 19 Jaromír Cápík 2014-04-03 12:31:49 EDT
I asked Jakub Čajka to do the review. If everything goes well, it should be finished the next week.
Comment 20 Rex Dieter 2014-04-03 14:42:26 EDT
Thanks!

*** This bug has been marked as a duplicate of bug 1084021 ***

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