Bug 477383 - [extremetuxracer] Please convert to new font packaging guidelines
[extremetuxracer] Please convert to new font packaging guidelines
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: extremetuxracer (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11-new-font-rules
  Show dependency treegraph
 
Reported: 2008-12-20 19:26 EST by Nicolas Mailhot
Modified: 2009-02-24 11:59 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-24 11:59:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2008-12-20 19:26:39 EST
This bug has been filed because we've detected your package includes one or several font files:                                                                                                                                                             repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb' -f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e 's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq                                                                                                                                                             Unfortunately the script does not detect symlinks to other packages, so if that's your case, you can close this bug report now.                                                                                                                                                              Otherwise, you should know that:                                                                                                                                                              - Fedora guidelines demand the packaging of fonts in a separate package or subpackage: http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages                                                                                - our font packaging guidelines recently changed, and every package that ships fonts must be adapted to the new templates available in the fontpackages-devel package. http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18) http://fedoraproject.org/wiki/Fedora_fonts_policy_package http://fedoraproject.org/wiki/Simple_fonts_spec_template http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts                                                                                                                                                              Please make your package conform to the current guidelines in rawhide.                                                                                                                                                             If your package is not principaly a font package, depending on a separate font package or subpackage is the prefered solution. If your application does not use fontconfig you can always package symlinks to the files provided by the font package and installed in the correct fontconfig directories.                                                                                                                                                              It is preferred to make a font package or subpackage per font family, though it is not currently a hard guidelines requirement (it may become before Fedora 11 is released). The definition of a font family is given on http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family                                                                                                                                                              The new templates should make the creation of font subpackages easy and safe.                                                                                                                                                              The following packages have already been converted and can serve as examples: - andika-fonts - apanov-heuristica-fonts - bitstream-vera-fonts - charis-fonts - dejavu-fonts - ecolier-court-fonts - edrip-fonts - gfs-ambrosia-fonts - gfs-artemisia-fonts - gfs-baskerville-fonts - gfs-bodoni-classic-fonts - gfs-bodoni-fonts - gfs-complutum-fonts - gfs-didot-classic-fonts - gfs-didot-fonts - gfs-eustace-fonts - gfs-fleischman-fonts - gfs-garaldus-fonts - gfs-gazis-fonts - gfs-jackson-fonts - gfs-neohellenic-fonts - gfs-nicefore-fonts - gfs-olga-fonts - gfs-porson-fonts - gfs-solomos-fonts - gfs-theokritos-fonts - stix-fonts - yanone-kaffeesatz-fonts                                                                                                                                                           If you have any remaining questions about the new guidelines please ask them on fedora-fonts-list at redhat.com
Comment 1 Nicolas Mailhot 2008-12-20 19:55:26 EST
[Since the bot made a mess of the text here it is again in properly indented form.]

This bug has been filed because we've detected your package includes one or several font files:

repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb' -f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e 's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq

Unfortunately this script does not detect symlinks to other packages, so if that's your case, you can close this bug report now.

Otherwise, you should know that:

— Fedora guidelines demand the packaging of fonts in a separate package (or subpackage):
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages

— our font packaging guidelines recently changed, and every package that ships fonts must be adapted to the new templates available in the fontpackages-devel package:
  – http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18)
  – http://fedoraproject.org/wiki/Fedora_fonts_policy_packagehttp://fedoraproject.org/wiki/Simple_fonts_spec_templatehttp://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

Please make your package conform to the current guidelines in rawhide (you can use the fontpackages package in F9 or F10 to test, but only submit changes to rawhide please).

If your package is not principaly a font package, depending on a separate font package or subpackage is the prefered solution. If your application does not use fontconfig you can always package symlinks to the files provided by the font package and installed in the correct fontconfig directories.

It is preferred to create a font package or subpackage per font family, though it is not currently a hard guidelines requirement (it may become before Fedora 11 is released). The definition of a font family is given on:
http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family

The new templates should make the creation of font subpackages easy and safe.

The following packages have already been converted by their packager and can serve as examples:
❄ andika-fonts
❄ apanov-heuristica-fonts
❄ bitstream-vera-fonts
❄ charis-fonts
❄ dejavu-fonts
❄ ecolier-court-fonts
❄ edrip-fonts
❄ gfs-ambrosia-fonts
❄ gfs-artemisia-fonts
❄ gfs-baskerville-fonts
❄ gfs-bodoni-classic-fonts
❄ gfs-bodoni-fonts
❄ gfs-complutum-fonts
❄ gfs-didot-classic-fonts
❄ gfs-didot-fonts
❄ gfs-eustace-fonts
❄ gfs-fleischman-fonts
❄ gfs-garaldus-fonts
❄ gfs-gazis-fonts
❄ gfs-jackson-fonts
❄ gfs-neohellenic-fonts
❄ gfs-nicefore-fonts
❄ gfs-olga-fonts
❄ gfs-porson-fonts
❄ gfs-solomos-fonts
❄ gfs-theokritos-fonts
❄ stix-fonts
❄ yanone-kaffeesatz-fonts

If you have any remaining questions about the new guidelines please ask them on:
fedora-fonts-list at redhat.com
Comment 2 Nicolas Mailhot 2009-01-11 10:19:21 EST
To help packagers manage the transition to the new guidelines, we've published the following FAQ

http://fedoraproject.org/wiki/Shipping_fonts_in_other_packages_(FAQ)
Comment 3 Nicolas Mailhot 2009-01-14 13:36:48 EST
FPC approved those two additional guidelines recently, please take them into account if you need to create or update a fonts package or subpackage:

– 2009-01-14: naming
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282009-01-13%29

— 2009-01-06: exact splitting rules
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29

(packagers that can drop font files and just depend on an existing font package are not impacted)
Comment 4 Nicolas Mailhot 2009-01-29 17:40:10 EST
(17:03:02) nphilipp: I'm struggling with making the extremetuxracer Fedora package compliant with the new font packaging guidelines...
(17:03:48) nphilipp: The package contains two font files, PaperCuts20.ttf and PaperCuts_outline.ttf
17:05
(17:05:01) nphilipp: I've read through the relevant guidelines in the Wiki, but they seem to center around pure font packages...
(17:05:43) nphilipp: Would it be correct to make a noarch subpackage "extremetuxracer-fonts" and leave the files in the same place?
(17:07:38) nphilipp: or would it have to be a "extremetuxracer-papercuts-fonts" package with files beneath /usr/share/fonts and symlinks in the mainpackage?

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#Can_I_just_put_all_my_fonts_in_a_-fonts_subpackage.3F

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#What_is_a_compliant_font_.28sub.29package.3F

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#If_I_make_my_font_subpackage_noarch_koji_crashes.21

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#But_my_application_crashes_if_I_remove_the_font_file.28s.29.21

Basically our packaging guidelines really want you to locate fonts original upstreams and package them in separate packages, but if you insist on subpackaging your subpackages must conform to guidelines (and there are no templates in that case because there is too much variability)

Also, you should put each separate font family in a separate (sub)package that can be installed without dragging in another font package or your app.
Comment 5 Nils Philippsen 2009-01-30 05:27:50 EST
(In reply to comment #4)

> Basically our packaging guidelines really want you to locate fonts original
> upstreams and package them in separate packages,

IIUC, I should be able to gleam some info about the font files with the gnome-font-viewer program. The problem is: I can't find it and using strings is a bit unsatisfactory ;-/. Do you know where I can get this program?

> but if you insist on
> subpackaging your subpackages must conform to guidelines (and there are no
> templates in that case because there is too much variability)
Comment 7 Nils Philippsen 2009-01-30 06:09:46 EST
Hmm, so gnome-font-viewer doesn't exist and fontforge crashes:

nils@gibraltar:~/devel/cvs/fedora/extremetuxracer/devel/extremetuxracer-0.4/data/fonts> fontforge PaperCuts20.ttf 
Copyright (c) 2000-2008 by George Williams.
 Executable based on sources from 00:23 GMT 28-Aug-2008.
 Library based on sources from 23:33 GMT 27-Aug-2008.
Help! Server claimed font
	-ibm-courier-medium-r-normal--16-0-0-0-m-0-iso10646-1
 existed in the font list, but when I asked for it there was nothing.
 I may crash soon.
Segmentation fault

Anything else I can try?
Comment 8 Nicolas Mailhot 2009-01-30 08:30:29 EST
This is a known xorg bug, I though it was fixed, if your system is up-to-date ask our xorg guys what the workaround is (I don't remember it).

Otherwise all those tools will do is permit direct access to font metadata, as the blurb says that's the same names that end in GUI font lists so you can always install your font files in fontconfig and just check what names appear in font lists then
Comment 9 Nicolas Mailhot 2009-02-18 14:32:02 EST
This is a reminder for all the packagers that still have bugs open about adapting to font packaging guidelines there is only one month left before Fedora 11 beta:
http://fedoraproject.org/wiki/Releases/11/Schedule

A week of this month will see the Fedora 11 mass rebuild, that will load the build farm:
http://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild

As already converted packages showed it is quite possible to make mistakes during the conversion. Please make releng and QA happy and don't wait till the last minute to do your changes (avoid pre-beta panic). If possible start before the mass rebuild so we don't burn cycles on incorrect packages.

The PackageKit enhancements stated for Fedora 11 assume fonts and font-using packages are sane (basically respect packaging guidelines). It is quite possible that not-converted packages will interact with the F11 font autoinstall feature in "interesting" ways.
http://fedoraproject.org/wiki/Features/AutomaticFontInstallation

We don't want that

There is extensive documentation on the wiki and most of your questions have likely already been answered there. Please do read the FAQ before making more work for the support team by asking questions answered there.
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29
Comment 10 Nils Philippsen 2009-02-19 05:38:41 EST
After I got fontforge working (bug #466404 and bug #450709), I looked into the font metadata:

It says that the font family is "PaperCuts 2.0". Would the resultant, compliant package name be "extremetuxracer-papercuts2_0-fonts"?

Two font files are included which have the same font in what I think is bold and outline weight. Still, the outline file says it is "bold" in its metadata. Should I fix this? Can you help me to do this properly?

The license for both files is this:
- "Names/Copyright": "Made for ETR by cpicon92. Based on Paper Cuts Daniel Poeira, licensed under the GPL. Czech alphabet and U+00A0, U+2009 and U+202f by Petr Pisar, 2007."
- "TTF Names/License": "The use of this font is granted subject to GNU General Public License."
- "TTF Names/Descriptor": "A combination of Free Sans Bold Oblique and Paper Cuts, made by cpicon92 for Extreme Tux Racer"
I know that GPL isn't an ideal license for a font, but is that acceptable?
Comment 11 Nicolas Mailhot 2009-02-20 12:24:32 EST
(In reply to comment #10)
> After I got fontforge working (bug #466404 and bug #450709), I looked into the
> font metadata:
> 
> It says that the font family is "PaperCuts 2.0". Would the resultant, compliant
> package name be "extremetuxracer-papercuts2_0-fonts"?

A strict reading of guidelines would be extremetuxracer-papercuts-2-0-fonts but unless there is a 1.0 somewhere I'd say just drop the whole 2.0 thing and use
 extremetuxracer-papercuts-fonts

> Two font files are included which have the same font in what I think is bold
> and outline weight. Still, the outline file says it is "bold" in its metadata.
> Should I fix this? Can you help me to do this properly?

Outline is not a "weight", and the fonts should belong to two different font families. Modern fonts can only have faces/styles differing in weight (bold/heavy), width (condensed/stretched), slant (italic/oblique), anything else confuses applications.

Still, they both say they're the "PaperCuts 2.0" font family in "BoldOblique". They should be font family A in Bold and font family B in bold (and drop the silly version-in-name)

That should be easy enough to fix with fontforge but needs to be done upstream.

I advise packaging them as extremetuxracer-papercuts-fonts and extremetuxracer-papercuts-outline-fonts with the files unchanged from upstream, and having the fonts fixed upstream

> The license for both files is this:
> - "Names/Copyright": "Made for ETR by cpicon92. Based on Paper Cuts Daniel
> Poeira, licensed under the GPL. Czech alphabet and U+00A0, U+2009 and U+202f by
> Petr Pisar, 2007."
> - "TTF Names/License": "The use of this font is granted subject to GNU General
> Public License."
> - "TTF Names/Descriptor": "A combination of Free Sans Bold Oblique and Paper
> Cuts, made by cpicon92 for Extreme Tux Racer"
> I know that GPL isn't an ideal license for a font, but is that acceptable?

We accept fonts under the GPL even if their use in embedding context is subject to debate. If you can reach the various authors and make them re-license under the GPL+font exception (with a specified GPL version range) that would be better of course. Current freefont is GPLv3 + font exception, but the version they used may have had some other licensing
Comment 12 Nils Philippsen 2009-02-24 11:59:41 EST
I've built extremetuxracer-0.4-2.fc11 in Rawhide which attempts to fix these issues. Please reopen if there is anything left to do.

Note You need to log in before you can comment on or make changes to this bug.