Bug 1001399 - OpenJPEG 2.0 has been released
Summary: OpenJPEG 2.0 has been released
Keywords:
Status: CLOSED DUPLICATE of bug 1084021
Alias: None
Product: Fedora
Classification: Fedora
Component: openjpeg
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaromír Cápík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 878782 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-27 00:56 UTC by Christopher Meng
Modified: 2016-02-01 01:59 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-03 18:42:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Christopher Meng 2013-08-27 00:56:31 UTC
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 16:52:23 UTC
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 17:03:54 UTC
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 17:07:05 UTC
(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 17:43:44 UTC
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 17:56:07 UTC
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 05:17:20 UTC
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 13:32:37 UTC
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 13:41:15 UTC
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 13:47:30 UTC
*** Bug 878782 has been marked as a duplicate of this bug. ***

Comment 10 Rex Dieter 2013-09-24 21:08:35 UTC
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 12:02:07 UTC
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 20:04:44 UTC
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 16:50:18 UTC
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 17:03:29 UTC
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 16:04:12 UTC
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 15:29:55 UTC
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 16:39:24 UTC
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 12:42:39 UTC
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 16:31:49 UTC
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 18:42:26 UTC
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.