Bug 477371

[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_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 (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

I have several problems to create a package for this font. 
- This font is not complete, it only has the main characters.
- The font has been altered for the game, for it didn't even had numbers.
- The upstream site does not have a download link, in fact the site is in flash and I cannot even put a link to the font page.

The only solution I can see for this is the following, create a sub package for the game that packages only the font. So the upstream becomes the altered font for the game.

My opinion is that the incomplete font is not very useful for much else then the game, that's why I packaged it with the game ignoring the "avoid bundling font..." rule.

you never know when a font is going to be of use to someone else; with the new templates creating a subpackage should be easy so yes, do that.

You'll still need to carefully review the font license, anyway

The license is "CC by attribution", I will do this as soon as possible.

This license is in the approved list so it should not pose a problem.

- The simple template installs the font into a {_fontdir} but does not define this macro, where should this font be installed? 

- What is this %{name}-fontconfig.conf file, is there a template or tool to create it?

- Is there a spec file that creates a font package as a sub-package so I could base my changes on?

If you add the fontpackages deps defined in the templates the macros will be imported correctly.

To create a fonts subpackage in a non-fonts package you just need to follow the simple template using the -n switch in the fonts macro to point to the correct subpackage name

Dumb me... all I had to do was install the package :P 

Could you check if I've done everything correctly, before I upload it to CVS?

The spec and srpm package are at :

http://bogado.net/rpm/cave9-0.3-4.bog10.src.rpm
http://bogado.net/rpm/cave9.spec

1. You need to specify the font files you installed in %_font_pkg
2. Since you know what sort of font it is, there is no reason not to ship a fontconfig file, you have simple templates in fontpackages-devel
3. do not forget to add the lines to claim ownership of %{_fontdir} after the %_font_pkg macro line

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)

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)

The font package naming says the package name must end in "fonts" (plural) does this stay true even for packages that contain only one font without any variations?

I made a new version of the spec file could you take a look?

http://bogado.net/rpm/cave9.spec
http://bogado.net/rpm/cave9-0.3-5.bog10.src.rpm

To quote the new naming guideline
"The use of the -fonts suffix is not dependant on the actual number of font files in the package."

Also I had to change the templates and macros slightly to take into account the naming changes requested by FPC, so before it hits stable releases please use "fontpackages-*-1.14" from rawhide to test your specs

I'm sorry for taking so long, my personal life is a little messed up right now, but I will do this as soon as I can manage it. I use stock F10, never ventured into Rawhide, so how do I do this, can I install it on my system or should I install a entirely new rawhide system?

np, I know what messed up means :(

You can do scratch builds in koji, for dist-f11, they'll use the new fontpackages. If you don't have access to a rawhide system, just look at the templates in the last bz2 archive on
http://fedorahosted.org/releases/f/o/fontpackages/

you don't need to actually install it to check the txt template files :)

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

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Hi, once again sorry for the BIIIG delay, as I said my life is going throgh a lot of changes right now, so my free time is limited.

I followed the font template on fedora 11 and got this result, could you check to see if it's all right?

http://static.bogado.net/rpm/cave9-0.3-6.bog11.src.rpm
http://static.bogado.net/rpm/cave9.spec

I just made a minor update on the files above, so if you happen to have them downloaded please re-download them, and sorry for the mess.

Another point the rpmlint tool gives me a warning 'dangling-relative-symlink /usr/share/cave9/hud.ttf ../../../usr/share/fonts/cave9/mutante.ttf' but this is only dangling if the required font package is not installed, otherwise the link is perfectly fine, I'm not sure how can I fix this.

(In reply to comment #19)
> I just made a minor update on the files above, so if you happen to have them
> downloaded please re-download them, and sorry for the mess.

NP
 
> Another point the rpmlint tool gives me a warning 'dangling-relative-symlink
> /usr/share/cave9/hud.ttf ../../../usr/share/fonts/cave9/mutante.ttf' but this
> is only dangling if the required font package is not installed, otherwise the
> link is perfectly fine, I'm not sure how can I fix this.  

You can ignore the dangling symlink warning since there's not really any way around it in your case

(BTW in Fedora we accept absolute symlinks so you don't need to play the ../.. game)

Looking at the files now...

(In reply to comment #18)

> I followed the font template on fedora 11 and got this result, could you check
> to see if it's all right?
> 
> http://static.bogado.net/rpm/cave9-0.3-6.bog11.src.rpm
> http://static.bogado.net/rpm/cave9.spec  

1. since the font licensing info is in the data README.txt, this file should be included as %doc in the font subpackage (just add a %doc myfile.txt after the %_font_pkg line)

2. you don't need to explicitely own the font directory, the macro will do it for you (and do it in the subpackage, which is the right place)

3. Your fontconfig file is bad. Start from the template in
/usr/share/fontconfig/templates/basic-font-template.conf
and use
/usr/share/fontconfig/templates/basic-font-template.txt
for instructions

In your case the generic family will likely be fantasy

That being said you've already done 80% of the work (thank you!), just the last mile to go now

There you are, I supose that now it should be ok. :p 

http://static.bogado.net/rpm/cave9-0.3-7.bog11.src.rpm
http://static.bogado.net/rpm/cave9.spec

1. you forgot to remove the
%dir %{_fontdir}
line (though at this stage it's harmless, just spec pollution)

2. Please use a fontconfig prefix in the 60-64 range, 50 would be a high-priority font ("fantasy" can be pretty much anything, but it'd be a shame to put a font with no bold and no italic first)

3. is there a reason you only use half of
/usr/share/fontconfig/templates/basic-font-template.conf ???
I know the two blocks in there seem very similar, but they have different affects and are not redundant.

4. you should put data_README.txt as doc in both packages, since it covers licensing for files that will end up in cave9-mutante-fonts and cave9 packages

Though 1 and 4 do not precisely concern the font subpackage, so you may ignore me there :p I'm a terrible perfectionist.

When I first picked '50' I thought it was a low priority. The problem is that I just that I don't understand this configuration file, this was the reason for removing the other half also, I thought it was redundant, silly me.

Perfectionism is good, the quality of fedora depends on this, that's why I'm making sure that everything is Ok before building and publishing the package. :-)

I think I got it now : 

http://static.bogado.net/rpm/cave9-0.3-8.bog11.src.rpm
http://static.bogado.net/rpm/cave9.spec

(In reply to comment #24)
> When I first picked '50' I thought it was a low priority. The problem is that I
> just that I don't understand this configuration file, this was the reason for
> removing the other half also, I thought it was redundant, silly me.

There are several short and to-the-point txt files in
/usr/share/fontconfig/templates/ (fontpackages-devel)

that try to explain the fontconfig aspects relevant to the average packager. If they're not sufficient or unclear, do not hesitate to complain on fedora-fonts-list at redhat.com (or open a fontpackages bug)

Well according to the document you pointed out, it seems to me that for all fantasy fonts there should not be the second half of the file. 

"— the second one tells fontconfig it can complete the font named [fontname]
with glyphs taken from fonts registered under [genericname]."

The argument is simple, fantasy fonts are generally used for their looks and the computer will not be able to guess witch is the best "compatible look" for the current project. So in my point of view, for fantasy fonts, the computer should display a missing glyph to the user instead of choosing another font that will probably surprise the user.

But I guess that this should be part of a larger policy, what do you think?

fontconfig will always try to complete the fonts and display something to the user. It's better if the user can read what you wanted to display than the user not being able to read computer messages at all (esp when those messages require action on his part).

What this rule does is help fontconfig choose the best class of fonts to pick from when it needs to complete. CSS works the same way in browsers

So you're saying that even without this fontconfig will try to complete. While I disagree that this is the way to go, I think that it is better that the system show me the error than trying to hide it, but this is more a philosophical issue.

But anyway, what did you think about the last version?

(In reply to comment #28)
> So you're saying that even without this fontconfig will try to complete.

Yes

> While
> I disagree that this is the way to go, I think that it is better that the
> system show me the error than trying to hide it, but this is more a
> philosophical issue.

Showing the error would be eating some text the computer directed at the user, which is not nice (TM)
 
> But anyway, what did you think about the last version?  

Oh, sorry, I don't see any other problem with this one

cave9-0.3-8.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/cave9-0.3-8.fc11

cave9-0.3-8.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/cave9-0.3-8.fc10

cave9-0.3-8.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cave9'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7379

cave9-0.3-8.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cave9'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7389

cave9-0.3-8.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

cave9-0.3-8.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.