Description of problem: texlive-base at 20210325-52.fc38 (source package) builds texlive-dvisvgm with dvisvgm at version 2.11.1. This version will FTBFS with ghostscript 10 (10.0.0 released upstream): this introduces an soname bump and api change, plus a new default PDF interpreter which will become the only choice in 10.1.0. rather than adjusting to the new PDF interpreter (which is already in gs 9.56) and the new API, dvisvgm upstream chose to switch tools, to mutool. 3.0 is the first version to do that: https://dvisvgm.de/News/ Version-Release number of selected component (if applicable): 20210325-52.fc38 How reproducible: Always Steps to Reproduce: Rebuild current texlive-base against ghostscript 10.0.0 (https://copr.fedorainfracloud.org/coprs/mjg/ghostscript/) Actual results: FTBFS (in copr against gs 10.0.0) Expected results: Workee! Additional info: There may be more obstacles on the way to gs 10 in Fedora. Working one by one.
Note that dvisvgm might already be broken in Fedora: "20 April 2022: dvisvgm 2.13.4 has been released Fixed the size of bounding boxes applied when converting multiple pages (issue #182). Try to enable the old PDF interpreter when using Ghostscript >= 9.56.0. dvisvgm does not work with Ghostscript’s new PDF interpreter." [https://dvisvgm.de/News/] While (our) gs 9.56.0 still has the switch to use the old PDF interpreter, our version of dvisvgm does not use it. (That may be different in TexLive 2022 but I have not checked.) Users will have to `export GS_OPTIONS=-dNEWPDF=false` themselves.
Hi Tom, any updates regarding the issue? Currently it is one of the issues blocking ghostscript rebase, which is needed by several projects I would like to package for Fedora 38.
I find it interestingly difficult to check which dvisvgm version is in texlive 2022. Apparantly, upstream TL 2022 has dvisvgm 2.13.3, which is bad news for us: This means that even with TeXLive 2022, dvisvgm is broken with gs 9.56.1 (in rawhide, f37, f36). I guess it's fair to say that no-one cared so far (user-wise). TeXLive 2023 will come too late for our deadlines, but dvisvgm is at 3.0.1 meanwhile, by the way. I'm note sure how often spot updates individual packages (out-of-band with TL).
Trying to glue dvisvgm 3.0.1 into texlive has left me with nothing but a giant, autotools invoked headache. I'll keep trying, but if anyone here can assist with a patch to do this, I would appreciate the assist.
Finally got it all untangled. texlive-base-20220321-58.fc38 will build a texlive-dvisvgm-svn64182.3.0.1-58.fc38.x86_64.rpm subpackage, which has dvisvgm 3.0.1 inside it (and a Requires: mupdf for mutool).
Kudos, Tom! Thank you for making it happen!
(In reply to Tom "spot" Callaway from comment #5) > Finally got it all untangled. texlive-base-20220321-58.fc38 will build a > texlive-dvisvgm-svn64182.3.0.1-58.fc38.x86_64.rpm subpackage, which has > dvisvgm 3.0.1 inside it (and a Requires: mupdf for mutool). Thanks a lot! Are you working from a source-git repo, by the way? I don't see the new version (64+ I assume) in a dist-git fork nor a copr. In any case, this together with the fixed doxygen bug helps tremendously to move forward with gs10 (and in turn with some cups stuff). Good news for F38!
I see two commits in my dist git clone - have you pulled the changes from upstream to your fork, Michael?
(In reply to Zdenek Dohnal from comment #8) > I see two commits in my dist git clone - have you pulled the changes from > upstream to your fork, Michael? I looked directly at https://src.fedoraproject.org/rpms/texlive and realised only now that there's a different one at https://src.fedoraproject.org/rpms/texlive-base with exactly the same description, and apparantly the same content minus the 4 most recent commits ... Curious.
(In reply to Michael J Gruber from comment #9) > (In reply to Zdenek Dohnal from comment #8) > > I see two commits in my dist git clone - have you pulled the changes from > > upstream to your fork, Michael? > > I looked directly at https://src.fedoraproject.org/rpms/texlive > > and realised only now that there's a different one at > > https://src.fedoraproject.org/rpms/texlive-base > > with exactly the same description, and apparantly the same content minus the > 4 most recent commits ... Curious. Hm, it might look that way at a very quick glance, but they're not the same. texlive-base is the TeXLive source code, which builds all of the architecture dependent binaries, along with the core noarch scripts/utilities that TeXLive includes in their source tarball. texlive contains all the other CTAN components which are needed to meet the dependencies for all of the collections and scheme groups. They're all noarch. ***** Also, I discovered that the rawhide toolchain is stricter on C++ headers than the F37 one, so I'm working on fixing the dvisvgm 3.0.1 patch to include extra #include <cstdint> lines as needed. Should have that resolved today.
(In reply to Michael J Gruber from comment #9) > I looked directly at https://src.fedoraproject.org/rpms/texlive > > and realised only now that there's a different one at > > https://src.fedoraproject.org/rpms/texlive-base Yeah, package naming is sometimes tricky :) so that's why I run 'dnf info' to find out real component name if I have a problem with package - so I can clone the right dist-git or report bugzilla :)
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.