Latest upstream release: 0.18 Current version/release in rawhide: 0.17-4.fc32 URL: https://jbig2dec.com Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/1431/
An HTTP error occurred downloading the package's new Source URLs: Getting https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs950/jbig2dec-0.18.tar.gz to ./jbig2dec-0.18.tar.gz
Jbig2dec 0.18 is in rawhide now I'd appreciate feedback from folks on F33/F32 which has the ghostscript that this jbig2dec version came with. Jbig2dec removed a few symbols that should be private anyways (and I kept the 0.17 patch which restored a needed symbol).
From koschei, this broke things [1] using Ghostscript, which seems to need a rebuild: ERROR ocrmypdf:ghostscript.py:203 2: jbig2dec FATAL ERROR decoding image: incompatible jbig2dec header (0.17) and library (0.18) versions **** Error reading a content stream. The page may be incomplete. Output may be incorrect. **** Error: File did not complete the page properly and may be damaged. Output may be incorrect. [1] https://koschei.fedoraproject.org/build/8343651
Adding GhostScript's folks into CC.
Hmm. Rawhide has the gs version that this jbig2dec version is intended for but was built against jbig2dec 0.17. Probably ghostscript should depend on the exact jbig2dec version which it was built against - this would have avoided the jbig2dec update until a rebuild of ghostscript. That is the only way how we can avoid the need for simultaneous builds and pushes (that I know of). Please let me know if there is anything I can do on the jbig2dec packaging side. (jbig2dec is notorious in terms of versionning and ABI)
I've updated gs's build requirements to match a specific jbig2dec version (0.16 for f31, 0.17 for f32 and 0.18 for rawhide, so to the one that it was built against) Here are related bodhi update requests: f31 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-3fa2780e1e f32 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-96b4f0be2b If there are any objections against that, please let me know
For jbig2dec itself I use Requires: %{name}-libs = %{version}-%{release} so that jig2dec depends on the %{version}-%{release} of jbig2dec-libs. Your change makes sure that ghostscript is built against a specific jbig2dec-devel version but - unless I'm mistaken - does not change the dependency of ghostscript on the library at all. That one is picked up automatically during the build, and because jbig2dec does not version the library properly this does not prevent the header (build time) vs. library (install time) mismatch. (I've asked upstream and they do not want to make any claims about ABI stability.)
FEDORA-2020-df4550580d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-df4550580d
jbig2dec-0.18-1.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-df4550580d
jbig2dec-0.18-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Anna Khaitovich from comment #6) > I've updated gs's build requirements to match a specific jbig2dec version > (0.16 for f31, 0.17 for f32 and 0.18 for rawhide, so to the one that it was > built against) > But since jbig2dec 0.18 is now in F32 (from the above update), this means Ghostscript is broken there again.
(In reply to Elliott Sales de Andrade from comment #11) > (In reply to Anna Khaitovich from comment #6) > > I've updated gs's build requirements to match a specific jbig2dec version > > (0.16 for f31, 0.17 for f32 and 0.18 for rawhide, so to the one that it was > > built against) > > > > But since jbig2dec 0.18 is now in F32 (from the above update), this means > Ghostscript is broken there again. On the contrary: if the dependency of gs is done correctly then having gs installed prevents jbig2dec from updating to a version that breaks gs. jbig2dec-0.18 is a bugfix update, and the easiest way to build gs against this version is to have this version in the repo. Once the rebuilt gs is in the repo both gs and jbig2dec can be updated via dnf.
(In reply to Michael J Gruber from comment #12) > (In reply to Elliott Sales de Andrade from comment #11) > > (In reply to Anna Khaitovich from comment #6) > > > I've updated gs's build requirements to match a specific jbig2dec version > > > (0.16 for f31, 0.17 for f32 and 0.18 for rawhide, so to the one that it was > > > built against) > > > > > > > But since jbig2dec 0.18 is now in F32 (from the above update), this means > > Ghostscript is broken there again. > > On the contrary: if the dependency of gs is done correctly then having gs > installed prevents jbig2dec from updating to a version that breaks gs. > Whether it is easier or not does not change the truth of my statement. It is _currently_ broken. > jbig2dec-0.18 is a bugfix update, and the easiest way to build gs against > this version is to have this version in the repo. Once the rebuilt gs is in > the repo both gs and jbig2dec can be updated via dnf. No, if jbig2dec does not do symbol versioning, then the easiest way is to treat it as a soversion bump, and coordinate with downstream packages. And then submit all packages together as *one* update. We have build root overrides, and temporary side tags. There is no reason that jbig2dec-0.18 *must* be in the stable repo before rebuilding ghostscript.
(In reply to Elliott Sales de Andrade from comment #13) ... Is there any concrete suggestion you have to make? jbig2dec can change ownership right now if someone wants to take it up.