Upstream has released 2.0 in 2012. http://www.openjpeg.org/index.php?menu=download Please update.
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.
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.
(co)maintainers welcome, for what it's worth... haven't had a chance to work on this one in awhile.
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.
depends if those symbols were part of the public api or not. but point taken, you know what you're doing. :)
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
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.
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?
*** Bug 878782 has been marked as a duplicate of this bug. ***
I would be against any compat packages, until there is a demonstrated need for them.
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.
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
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.
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
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.
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
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.
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
I asked Jakub Čajka to do the review. If everything goes well, it should be finished the next week.
Thanks! *** This bug has been marked as a duplicate of bug 1084021 ***