Hello. Currently we ship urw-fonts, which originate from http://svn.ghostscript.com/ghostscript/trunk/urw-fonts/. This repo hasn't been updated since 2008. Updated versions of urw-fonts are available at http://git.ghostscript.com/?p=urw-core35-fonts.git;a=summary. New license is AGPL3 (with exceptions). Note that Fedora attempted to switch to this repo too, but reverted later: http://pkgs.fedoraproject.org/cgit/rpms/urw-fonts.git/commit/?id=093877f112a35d99fa8b99abf4359e274c68985f http://pkgs.fedoraproject.org/cgit/rpms/urw-fonts.git/commit/?id=22c72f677885eddac22d574eb5c481a4c1bf1d09 http://pkgs.fedoraproject.org/cgit/rpms/urw-fonts.git/commit/?id=edb2b38c9da9b9f2e82d981cbedbfaa7f1ad1054 I cannot say for sure, but it could be due to AGPL vs GPL+ license. It shouldn't be a problem in Gentoo though. Please consider using new upstream and doing a verbump.
The font names changed as well, so any switch here *MUST* be coordinated with a new app-text/ghostscript-gpl revbump (changing the patches). Otherwise GS won't find its fonts anymore and crash.
From the Fedora changelog: * Tue Jan 20 2015 Than Ngo <than@redhat.com> 3:2.4-20 - revert * Tue Sep 09 2014 Than Ngo <than@redhat.com> - 2:1.10-1 - update to 1.10 - use upstream version, increase Epoch - update new license
If I'm not mistaken, ghostscript-gpl ships its own copy of required fonts in /usr/share/ghostscript-${PV}/Resources/Font so no patch should be needed. Regarding the versions, as indicated in /etc/fonts/conf.avail/30-metric-aliases.conf (part of media-libs/fontconfig), artifex software (actual copyright owner, AFAICT) distributes fonts (and confs) at https://github.com/ArtifexSoftware/urw-base35-fonts/ (current release 20170801). A few months ago, I tested on my system a partially patched ghostscript-gpl (I apply all the patches but the ghostscript-9.20-urw-fonts-naming.patch) and switched to a urw-fonts package based on the artifex software release (in otf format). So far, all seems to work.
Created attachment 513856 [details] modified ghostscript ebuild ebuild which removes selectively ghostscript-9.20-urw-fonts-naming.patch
Created attachment 513858 [details] urw otf fonts ebuild urw-fonts ebuild based on github sources
Fedora also switched to this upstream and their patched ghostscript works for it https://src.fedoraproject.org/rpms/urw-base35-fonts/blob/master/f/urw-base35-fonts.spec
As I read in Fedora .spec file, it seems that we need to provide both: the old fonts and the new ones. They are applying them on a "legacy" subdir (the old ones) and probably patching the reverse deps needing them to look for them there. But seeing that they don't overlap, I would simply unpack the old and the new sources and install all together in the current installation dir
Could someone move the bug forward here please as it is causing KDE upstream bug reports from Gentoo users.
Created attachment 695889 [details] urw-fonts-20200910.ebuild Fix broken ebuild due to EAPI updates on the font eclass. Everything still seems to work after bumping up EAPI. Also, latest version upstream is now 20200910. So I bumped our version to match.
Ping?
Just checked both debian and fedora, and they both use the new github repository as upstream. I think it's time to switch. https://github.com/ArtifexSoftware/urw-base35-fonts
Created attachment 863548 [details] urw-fonts-20230503.ebuild For now I am running this one locally. - It uses the latest snapshot as it includes patches other distributions are applying over the older 2020 version. - I dropped the legacy fonts as I am unsure they are still needed. This last point is the most problematic and the reason I didn't went ahead and commit. For example on Arch, they simply dropped the old fonts, in Fedora they provide all of them with the same package... making the package a bit more complex. From my point of view, I would try to push only the new font set... but if legacy fonts are really needed by many... maybe we should use a separate package for the new fonts and keep the old package as-is :/ Other option could be to commit this hardmasked to see how reverse deps work with it... but I think it won't be really tested until it lands testing. Thanks for your thoughts
(In reply to Pacho Ramos from comment #12) > From my point of view, I would try to push only the new font set... but if > legacy fonts are really needed by many... maybe we should use a separate > package for the new fonts and keep the old package as-is :/ Slot it? This will break rev deps when they need the old fonts and the new slot contains the new fonts only, but these broken rev deps could easily be fixed by making them depend on the old slot.
But they conflict with: * Detected file collision(s): * * /usr/share/fonts/urw-fonts/encodings.dir * /usr/share/fonts/urw-fonts/fonts.dir * /usr/share/fonts/urw-fonts/fonts.scale Anyway, I think we could simply push it and see what old stuff breaks. I guess most of that stuff will be fixable or probably is too old and deserves to be treecleaned
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8dd70d61f3f6c73aecf5c36b8026f1f8016a0f8e commit 8dd70d61f3f6c73aecf5c36b8026f1f8016a0f8e Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2023-07-29 10:02:37 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2023-07-29 10:13:05 +0000 media-fonts/urw-fonts: add 20230503 New upstream. It uses the latest snapshot as it includes patches other distributions are applying over the older 2020 version. Legacy fonts dropped for now as they add extra complexity to the ebuild, some distros killed them years ago without issues and the reverse deps I have tried still work fine without them. If some old stuff breaks, feel free to report and we will see how to proceed with them. Bug: https://bugs.gentoo.org/589890 Signed-off-by: Pacho Ramos <pacho@gentoo.org> media-fonts/urw-fonts/Manifest | 1 + media-fonts/urw-fonts/urw-fonts-20230503.ebuild | 50 +++++++++++++++++++++++++ 2 files changed, 51 insertions(+)
*** Bug 621100 has been marked as a duplicate of this bug. ***
