Bug 1818706

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.