Summary: | app-text/ghostscript-gpl built on Gentoo behaves differently from official build (app-text/poppler-data is missing extra files) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Guillaume Ayoub <guillaume> |
Component: | Current packages | Assignee: | Codec Project <codec> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, mgorny, orzel, printing, prochronism, proteuss, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=851141 https://bugs.gentoo.org/show_bug.cgi?id=852944 https://bugs.gentoo.org/show_bug.cgi?id=873889 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 862133 | ||
Attachments: |
PDF sample
fixed ebuild Identity-H Identity-V Identity-UTF16-H |
Description
Guillaume Ayoub
2022-05-13 22:40:51 UTC
Created attachment 778649 [details]
PDF sample
Were older versions fine? (In reply to Sam James from comment #2) > Were older versions fine? Yes, there’s no problem with 9.55.0. (In reply to Guillaume Ayoub from comment #3) > (In reply to Sam James from comment #2) > > Were older versions fine? > > Yes, there’s no problem with 9.55.0. Could you try building from source and see if it makes any difference? Like, manually, w/oo ebuild, etc? Want to narrow it down as much as possible. (In reply to Sam James from comment #4) > (In reply to Guillaume Ayoub from comment #3) > > (In reply to Sam James from comment #2) > > > Were older versions fine? > > > > Yes, there’s no problem with 9.55.0. > > Could you try building from source and see if it makes any difference? Like, > manually, w/oo ebuild, etc? Want to narrow it down as much as possible. I’ve downloaded the source tarball and compiled it ("./configure", "make", no explicit option). The problem also appears with this manually compiled version. The problem is not in the ebuild… Do you have another idea to find where it comes from? I’ve let Ghostscript’s configure use its own default C and C++ compilation options: - C compiler: x86_64-pc-linux-gnu-gcc -DHAVE_RESTRICT=1 -DUSE_LIBPAPER -Wall -W - C++ compiler: x86_64-pc-linux-gnu-g++ -std=c++17 It doesn’t fix the problem. (In reply to Guillaume Ayoub from comment #5) > (In reply to Sam James from comment #4) > > (In reply to Guillaume Ayoub from comment #3) > > > (In reply to Sam James from comment #2) > > > > Were older versions fine? > > > > > > Yes, there’s no problem with 9.55.0. > > > > Could you try building from source and see if it makes any difference? Like, > > manually, w/oo ebuild, etc? Want to narrow it down as much as possible. > > I’ve downloaded the source tarball and compiled it ("./configure", "make", > no explicit option). > > The problem also appears with this manually compiled version. The problem is > not in the ebuild… Do you have another idea to find where it comes from? I'm really struggling here. I've compared the ebuilds to Fedora and Arch's packaging, but it looks.. fine. And if it happens when building manually, it must be one of our dependencies, right? But if the Fedora or Arch binaries work for you, given they don't statically link stuff, it means it must be in how it was built. The only thing I can think of is some bundled library copy they're using, but it still doesn't make sense if a manual build fails with no patching. We did have a bug with lcms2 a little while ago, but it got fixed upstream (and we'd backported the patch before they made a fix release even): bug 832520. Perhaps if someone has some time, they could try using Fedora or Arch packages on Gentoo (if they are compatible with Gentoo's shared libraries). (In reply to Michał Górny from comment #8) > Perhaps if someone has some time, they could try using Fedora or Arch > packages on Gentoo (if they are compatible with Gentoo's shared libraries). Arch’s package has the bug when used on my Gentoo laptop. But there’s no bug on Arch. (If anyone wants to try, download and unzip Arch’s ghostscript and libjpeg-turbo packages, and set LD_LIBRARY_PATH=<unzip-path>/usr/lib/ GS_LIB=<unzip-path>/usr/share/ghostscript/Resource/Init/ environment variables. Arch’s libjpeg-turbo package is not compatible with Gentoo’s.) (In reply to Guillaume Ayoub from comment #9) > (In reply to Michał Górny from comment #8) > > Perhaps if someone has some time, they could try using Fedora or Arch > > packages on Gentoo (if they are compatible with Gentoo's shared libraries). > > Arch’s package has the bug when used on my Gentoo laptop. But there’s no bug > on Arch. > > (If anyone wants to try, download and unzip Arch’s ghostscript and > libjpeg-turbo packages, and set LD_LIBRARY_PATH=<unzip-path>/usr/lib/ > GS_LIB=<unzip-path>/usr/share/ghostscript/Resource/Init/ environment > variables. Arch’s libjpeg-turbo package is not compatible with Gentoo’s.) Okay, I think this is helpful. Next step is to compare the versions dependencies of GS dependencies on Arch vs Gentoo (not the versions listed in the ebuild, just the versions of each dependency in reality that are installed). (In reply to Sam James from comment #10) > Okay, I think this is helpful. Next step is to compare the versions > dependencies of GS dependencies on Arch vs Gentoo (not the versions listed > in the ebuild, just the versions of each dependency in reality that are > installed). I’ve tried to find some differences, but nothing obvious. OK. It’s time to find the source of the problem. FOR REAL. It’s BISECT TIME 🤯. The bug has been introduced by http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=42dca5ca192296b4cf40dd61f2eb61e062a1d449 Especially this part: http://git.ghostscript.com/?p=ghostpdl.git;a=blobdiff;f=base/fapi_ft.c;h=39dccc7d4f1d9ecdd9f34dcaca33a2cc3a76b74e;hp=d02453b795cdbce7972e93264613e5dbcf879589;hb=42dca5ca192296b4cf40dd61f2eb61e062a1d449;hpb=5e3eee0376626bc7d978b5136ac3f9d73d116bc5 Applying the reverse patch makes 9.56.1 work correctly for me. Random thoughts: - Arch’s package may work because it doesn’t remove in-tree freetype [1] as Gentoo’s ebuild does [2]. I’ve tried to keep the freetype folder in Gentoo’s ebuild, but it doesn’t work. Long story short: I have no idea of what’s going on. - The sample attached in this bug uses small fonts (makes sense), but that’s probably not the case of bug 851141. [1] https://github.com/archlinux/svntogit-packages/blob/packages/ghostscript/trunk/PKGBUILD#L51 [2] https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/ghostscript-gpl/ghostscript-gpl-9.56.1.ebuild#n74 (In reply to Guillaume Ayoub from comment #12) > The bug has been introduced by > http://git.ghostscript.com/?p=ghostpdl.git;a=commit; > h=42dca5ca192296b4cf40dd61f2eb61e062a1d449 > > Especially this part: > http://git.ghostscript.com/?p=ghostpdl.git;a=blobdiff;f=base/fapi_ft.c; > h=39dccc7d4f1d9ecdd9f34dcaca33a2cc3a76b74e; > hp=d02453b795cdbce7972e93264613e5dbcf879589; > hb=42dca5ca192296b4cf40dd61f2eb61e062a1d449; > hpb=5e3eee0376626bc7d978b5136ac3f9d73d116bc5 > > Applying the reverse patch makes 9.56.1 work correctly for me. > > Random thoughts: > > - Arch’s package may work because it doesn’t remove in-tree freetype [1] as > Gentoo’s ebuild does [2]. I’ve tried to keep the freetype folder in Gentoo’s > ebuild, but it doesn’t work. Long story short: I have no idea of what’s > going on. > > - The sample attached in this bug uses small fonts (makes sense), but that’s > probably not the case of bug 851141. > > [1] > https://github.com/archlinux/svntogit-packages/blob/packages/ghostscript/ > trunk/PKGBUILD#L51 > [2] > https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/ghostscript-gpl/ > ghostscript-gpl-9.56.1.ebuild#n74 Fantastic! Could you report it upstream? (In reply to Sam James from comment #13) > Fantastic! Could you report it upstream? Before reporting the bug upstream, we’d probably like to solve the last mystery: why does it work on other distributions? Ghostscript’s binary works on Gentoo, the distribution package (built from the sources) works on Arch. For now, there’s no evidence that the "bug" can be reproduced on any distribution other than Gentoo, and that’s a problem if we want the Ghostscript’s devs to reproduce and solve it. As Arch’s package has the bug when used on Gentoo, we can assume that the root of the bug is in another package (Freetype?) that’s different when built on Gentoo and on Arch. If anyone has an idea to find where the problem is, I can spend more time on this issue, but currently I don’t really know what to do :/. I would start by playing with freetype's USE flags. (In reply to Michał Górny from comment #15) > I would start by playing with freetype's USE flags. While checking the differences of the build options of Freetype on Gentoo and Arch, I’ve tried to apply the patch on Gentoo’s package instead of building from the sources. This way, I thought I could at least have Ghostscript’s ebuild working on my computer without the bug. But now, I’m desperate. - When building 9.56.1 from the git repository (ghostpdl-9.56.1 tag), I get the bug. - When building 9.56.1 from the git repository (ghostpdl-9.56.1 tag) with the reverse patch, I do not get the bug. - When building 9.56.1 from the ebuild, I get the bug. - When building 9.56.1 from the ebuild with the reverse patch, I GET THE BUG 😡. I’ve checked everything. I can see that the patch is applied when building from the ebuild, I’m sure that the patch applied to the git repository is exactly the same as the one applied to the ebuild. But it doesn’t fix the bug for the ebuild, only for the git repository. And of course, everything works WITHOUT the patch on other distributions, and even on Gentoo when we use the official build. It doesn’t make sense. I can try to play with Freetype’s USE flags, but I doubt that there’s something wrong with them from what I can say of Arch’s build options. Ghostscript includes its own copy of Freetype, I don’t know the differences with upstream and just "bisecting" these differences could take days. And that’s only for Freetype, but the same applies to other bundled libraries. I’ll try different random things when I can find more time. I can feel your pain. Believe me, I know what you're going through and even more I'd like to thank you for trying to figure this out. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a7e7e2e1e67ce3374bafba51b9cdd271f29b48d2 commit a7e7e2e1e67ce3374bafba51b9cdd271f29b48d2 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-08-02 03:38:32 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-08-02 03:38:57 +0000 profiles: mask broken ghostscript-gpl-9.56.1 We should've done this earlier, even. Bug: https://bugs.gentoo.org/844115 Bug: https://bugs.gentoo.org/851141 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 4 ++++ 1 file changed, 4 insertions(+) I've taken a brief look into this bug over the weekend. My findings: 1. Repro'd failure on emerge build 2. Unable to repro failure when building the same tag from upstream git (output matches upstream binaries) I removed the 'quiet' flag, and noted that we receive *different output* from each binary. upstream binary: ``` GPL Ghostscript 9.56.1 (2022-04-04) Copyright (C) 2022 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Processing pages 1 through 2. Page 1 Page 2 ``` git ``` GPL Ghostscript 9.56.1 (2022-04-04) Copyright (C) 2022 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Unknown .defaultpapersize: (A4). Processing pages 1 through 2. Page 1 Page 2 ``` emerge: ``` GPL Ghostscript 9.56.1 (2022-04-04) Copyright (C) 2022 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Unknown .defaultpapersize: (A4). Processing pages 1 through 2. Page 1 Loading font TWQBVK (or substitute) from /usr/share/ghostscript/9.56.1/Resource/Font/NimbusSans-Regular Loading font TWQBVK (or substitute) from /usr/share/ghostscript/9.56.1/Resource/Font/NimbusSans-Regular Page 2 Loading font TWQBVK (or substitute) from /usr/share/ghostscript/9.56.1/Resource/Font/NimbusSans-Regular Loading font TWQBVK (or substitute) from /usr/share/ghostscript/9.56.1/Resource/Font/NimbusSans-Regular ``` Based on the different outputs here, I suspect that something in the following function is causing the difference that we're seeing: https://github.com/ArtifexSoftware/ghostpdl/blob/ghostpdl-9.56.1/pdf/pdf_font.c#L528 I'll need to dig into why that actually differs a bit later on today (if I have time). As a stretch goal, I'd like to work out why the upstream binary doesn't throw `Unknown .defaultpapersize: (A4).` while both compiled on my machine do; that might be a quick query for upstream though! @Matt Thanks a lot for taking the time to find what’s wrong. @all I’ve tried to compile the new 10.0.0 version, I get the same bug. Ghostscript's official binary is built with bundled CMaps; on Gentoo, these are unbundled in favor of those provided by app-text/poppler-data. Ghostscript's CMaps include 3 files missing from poppler-data: Identity-H, Identity-V, and Identity-UTF16-H (CMap resources for the special-purpose Adobe Identity-0 ROS), and the lack of these files is causing this issue. Fedora and Arch avoid this problem by using GS-bundled CMaps, while Debian (and older versions of Fedora) relies on CMaps from poppler-data (like Gentoo does) and includes the missing files in their poppler-data package, installing them to /usr/share/poppler/cMap. (According to Debian, upstream poppler-data refuses to include them.) Two of these files are provided by Adobe Type Tools: https://github.com/adobe-type-tools/cmap-resources/tree/master/Adobe-Identity-0/CMap and the third is from Artifex themselves: http://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=Resource/CMap/Identity-UTF16-H;hb=HEAD You can copy these 3 files to /usr/share/poppler/cMaps for a quick-and-dirty verification that they resolve the issue; by doing so, I was able to produce a match for gs-fail-good.jpg and pass the WeasyPrint test suite using ghostscript-gpl-9.56.1 (and 10.0). Including these files with poppler-data seems like the best approach. (As noted in Ghostscript's LICENSE file, Identity-UTF16-H is licensed under AGPL-3+.) Created attachment 814879 [details]
fixed ebuild
Created attachment 814882 [details]
Identity-H
Created attachment 814885 [details]
Identity-V
Created attachment 814888 [details]
Identity-UTF16-H
Thanks a ton for figuring this out! The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=21675840cadb15ceb9e3597f43da2f199d70240a commit 21675840cadb15ceb9e3597f43da2f199d70240a Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-01 06:54:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-01 06:54:40 +0000 profiles: unmask ghostscript 9.56 Closes: https://bugs.gentoo.org/844115 Closes: https://bugs.gentoo.org/851141 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 4 ---- 1 file changed, 4 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0ecd6cf254f4d76419fd05f80095f134513f7856 commit 0ecd6cf254f4d76419fd05f80095f134513f7856 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-01 06:54:16 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-01 06:54:16 +0000 app-text/ghostscript-gpl: depend on newer poppler-data w/ needed files Closes: https://bugs.gentoo.org/844115 Signed-off-by: Sam James <sam@gentoo.org> ...ostscript-gpl-9.56.1-r1.ebuild => ghostscript-gpl-9.56.1-r2.ebuild} | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f7d3daf96af5d450b3f983df77129c5aeac3c376 commit f7d3daf96af5d450b3f983df77129c5aeac3c376 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-01 06:49:48 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-01 06:52:03 +0000 app-text/poppler-data: add additional cMaps files needed by ghostscript Quoting John from the Bug; >Ghostscript's official binary is built with bundled CMaps; on Gentoo, these are unbundled >in favor of those provided by app-text/poppler-data. Ghostscript's CMaps include 3 files >missing from poppler-data: Identity-H, Identity-V, and Identity-UTF16-H (CMap >resources for the special-purpose Adobe Identity-0 ROS), and the lack of these files is causing this issue. > >Fedora and Arch avoid this problem by using GS-bundled CMaps, while Debian >(and older versions of Fedora) relies on CMaps from poppler-data (like Gentoo does) >and includes the missing files in their poppler-data package, installing them to >/usr/share/poppler/cMap. (According to Debian, upstream poppler-data refuses to include them.) > >Two of these files are provided by Adobe Type Tools: >https://github.com/adobe-type-tools/cmap-resources/tree/master/Adobe-Identity-0/CMap > >and the third is from Artifex themselves: >http://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=Resource/CMap/Identity-UTF16-H;hb=HEAD > >You can copy these 3 files to /usr/share/poppler/cMaps for a quick-and-dirty verification that >they resolve the issue; by doing so, I was able to produce a match for gs-fail-good.jpg and >pass the WeasyPrint test suite using ghostscript-gpl-9.56.1 (and 10.0). Including >these files with poppler-data seems like the best approach. (As noted in >Ghostscript's LICENSE file, Identity-UTF16-H is licensed under AGPL-3+.) Bug: https://bugs.gentoo.org/844115 Thanks-to: John Wudrick <prochronism@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> app-text/poppler-data/Manifest | 1 + .../poppler-data/poppler-data-0.4.11-r1.ebuild | 27 ++++++++++++++++++++++ 2 files changed, 28 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3bb47ccd664800bbac42aa90e70ab73058482bd7 commit 3bb47ccd664800bbac42aa90e70ab73058482bd7 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-01 07:20:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-01 08:32:50 +0000 dev-python/weasyprint: update ghostscript test dep Bug: https://bugs.gentoo.org/844115 Signed-off-by: Sam James <sam@gentoo.org> dev-python/weasyprint/weasyprint-55.0.ebuild | 5 ++++- dev-python/weasyprint/weasyprint-56.0.ebuild | 5 ++++- dev-python/weasyprint/weasyprint-56.1.ebuild | 5 ++++- 3 files changed, 12 insertions(+), 3 deletions(-) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e22155a75b4d1b45115719ea6c1db112614b449d commit e22155a75b4d1b45115719ea6c1db112614b449d Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-02 03:14:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-02 03:14:41 +0000 dev-python/weasyprint: adjust ghostscript dep I made an error in the poppler-data original fix, so depend on fixed GS again (with a fixed dep). Closes: https://bugs.gentoo.org/844115 Closes: https://bugs.gentoo.org/851141 Closes: https://bugs.gentoo.org/873889 Signed-off-by: Sam James <sam@gentoo.org> dev-python/weasyprint/weasyprint-55.0.ebuild | 2 +- dev-python/weasyprint/weasyprint-56.0.ebuild | 2 +- dev-python/weasyprint/weasyprint-56.1.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=541c89d3edb13847d272b6b700fde7505830dea0 commit 541c89d3edb13847d272b6b700fde7505830dea0 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-02 03:14:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-02 03:14:08 +0000 app-text/ghostscript-gpl: crank up poppler-data dep again I typo'd the paths previously. Closes: https://bugs.gentoo.org/844115 Closes: https://bugs.gentoo.org/851141 Closes: https://bugs.gentoo.org/873889 Signed-off-by: Sam James <sam@gentoo.org> ...hostscript-gpl-9.56.1-r2.ebuild => ghostscript-gpl-9.56.1-r3.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f12b8ad09be64a20685b7c87fdb4dbbc2b7f8a56 commit f12b8ad09be64a20685b7c87fdb4dbbc2b7f8a56 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-02 03:12:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-02 03:13:39 +0000 app-text/poppler-data: fix extra file paths Closes: https://bugs.gentoo.org/844115 Closes: https://bugs.gentoo.org/851141 Closes: https://bugs.gentoo.org/873889 Fixes: f7d3daf96af5d450b3f983df77129c5aeac3c376 Signed-off-by: Sam James <sam@gentoo.org> app-text/poppler-data/Manifest | 2 +- .../{poppler-data-0.4.11-r1.ebuild => poppler-data-0.4.11-r2.ebuild} | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Thanks a lot for the work done to close this bug. I’ve updated poppler-data and ghostscript, I have the new Identity-* files in /usr/share/poppler/cMaps, but unfortunately ghostscript-10 (installed from ebuild) still gives the wrong rendering with the "Loading font TWQBVK (or substitute) from …" messages. Did I forget to do something? (In reply to Guillaume Ayoub from comment #30) > Thanks a lot for the work done to close this bug. > > I’ve updated poppler-data and ghostscript, I have the new Identity-* files > in /usr/share/poppler/cMaps, but unfortunately ghostscript-10 (installed > from ebuild) still gives the wrong rendering with the "Loading font TWQBVK > (or substitute) from …" messages. > > Did I forget to do something? Huh. Good question. I assumed everything was fine because the weasyprint tests passed now. (In reply to Sam James from comment #31) > (In reply to Guillaume Ayoub from comment #30) > > Thanks a lot for the work done to close this bug. > > > > I’ve updated poppler-data and ghostscript, I have the new Identity-* files > > in /usr/share/poppler/cMaps, but unfortunately ghostscript-10 (installed > > from ebuild) still gives the wrong rendering with the "Loading font TWQBVK > > (or substitute) from …" messages. > > > > Did I forget to do something? > > Huh. Good question. I assumed everything was fine because the weasyprint > tests passed now. I’ve found what’s wrong: ghostscript-gpl-10.0.0 installs files in /usr/share/ghostscript/10.00.0, but the CMap folder is installed in /usr/share/ghostscript/10.0.0 (one 0 is missing). Moving the folder into 10.00.0 fixes the problem. (In reply to Guillaume Ayoub from comment #32) > (In reply to Sam James from comment #31) > > (In reply to Guillaume Ayoub from comment #30) > > > Thanks a lot for the work done to close this bug. > > > > > > I’ve updated poppler-data and ghostscript, I have the new Identity-* files > > > in /usr/share/poppler/cMaps, but unfortunately ghostscript-10 (installed > > > from ebuild) still gives the wrong rendering with the "Loading font TWQBVK > > > (or substitute) from …" messages. > > > > > > Did I forget to do something? > > > > Huh. Good question. I assumed everything was fine because the weasyprint > > tests passed now. > > I’ve found what’s wrong: ghostscript-gpl-10.0.0 installs files in > /usr/share/ghostscript/10.00.0, but the CMap folder is installed in > /usr/share/ghostscript/10.0.0 (one 0 is missing). > > Moving the folder into 10.00.0 fixes the problem. Nice find, but now I'm wondering how to detect something like this, given the tarball really is 10.00.0. I guess I can check what folder in ${ED}/usr/share/ghostscript/* exists and use that for the symlink. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=442db4d45a15b497cf43e75e3ad38ae90aaaabbc commit 442db4d45a15b497cf43e75e3ad38ae90aaaabbc Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-04 09:08:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-04 09:08:59 +0000 app-text/ghostscript-gpl: fix version used for /usr/share/poppler/* symlink Sometimes it deviates from the actual tarball & tag version, apparently. Closes: https://bugs.gentoo.org/844115 Thanks-to: Guillaume Ayoub <guillaume@yabz.fr> Signed-off-by: Sam James <sam@gentoo.org> ...stscript-gpl-10.0.0.ebuild => ghostscript-gpl-10.0.0-r1.ebuild} | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) |